COMMUNICATIONS STANDARDS REVIEW … And Q15/16 June 24 – 27, 1997, Portland, Or ... Texas...

July-August 1997 Vol. 8.7 Copyright © CSR 1997 1

COMMUNICATIONS STANDARDSREVIEW

TELECOMMUNICATIONS

Volume 8, Number 7 July-August 1997

IN THIS ISSUE

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

TR-30.2, digital interfaces, including DTE-DCE protocols, June 13, 1997, Costa Mesa, CA............................2TR-30.2 Meeting Roster, June 13, 1997, Costa Mesa, CA.................................................................3

Q12/16, Q13/16 and Q14/16 Rapporteur Meetings, June 10 – 13, 1997, Herzlia, Israel...................................4Q12/16, B-ISDN multimedia systems and terminals.........................................................................4Q13/16, Packet-Switched Multimedia Systems and Terminals.............................................................6Q14/16, Common protocols, MCUs and protocols for interworking with H.3xx terminals.........................12Q12/16, Q13/16,-Q14/16 Rapporteur Meeting Roster, June 10 – 13, 1997, Herzlia, Israel.........................15

ETSI Technical Committee/Speech Processing, Transmission, And Quality Aspects (TC/STQ)June 23 – 24, 1997, Sophia Antipolis, France..........................................................................16

Study Group 8 Q1/8 and Q4/8 Rapporteur Meetings, June 23 – 27, 1997, Costa Mesa, CA...............................19Question 1/8, Facsimile Terminals..............................................................................................19Question 4/8, Document Communication Services..........................................................................23

Q11/16 And Q15/16 June 24 – 27, 1997, Portland, Or...........................................................................26Q11/16, Circuit-Switched Network (CSN) Multimedia Systems and Terminals.........................................26Brief Report of Q15/16, Advanced Video Coding.............................................................................33Q11/16 and Q15/16 Meeting Roster, June 24 – 27, 1997, Portland, OR................................................36

Q18/16, Interaction of High-Speed Voiceband Data Systems with Signal Processing Equipment in the GSTNJune 26 – 27, 1997, Amsterdam, The Netherlands......................................................................37

Q18/16 Meeting Roster, June 26 – 27, 1997, Amsterdam, The Netherlands............................................40Second Etsi Project, Multimedia Terminal And Applications, June 30 - July 4, 1997, Sophia Antipolis, France.....40

ETSI/MTA Attendance Roster, June 30 – July 4, 1997, Sophia Antipolis, France.....................................46Q4/16, Q7/16, Q8/16, and Q23/16 Rapporteur’s Meetings, July 7 – 11, 1997, Dublin, Ireland..........................46

Q4/16, V.8bis.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Q7/16, DCE/DCE Protocols.......................................................................................................47Q8/16, DCE/DCE Protocols.......................................................................................................49Q23/16, PCM modem....... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50Q23/16 Ad Hoc Meeting on V.PCM Startup...................................................................................52Roster for SG 16 Q4/16, Q7/16 and Q23/16 RAPPORTEUR’S Meetings, July 7 – 11, 1997, Dublin, Ireland....54

IMTC Ad-Hoc Group on Harmonization of Conferencing Protocols, July 8 – 10, 1997, Andover, MA.................55Meeting Roster for IMTC Ad-Hoc Group on Harmonization of Conferencing Protocols,July 8 – 10, 1997, Andover, MA.................................................................................................57

Question 4/15, Access Network Systems (xDSL), Rapporteurs Meeting, July 14 – 15, 1997, Columbia, MD.........58Q4/15 Meeting Roster, July 14-15, 1997, Columbia, MD.................................................................61

Q3/16, Data Protocols For Multimedia Conferencing, July 15 – 18, 1997, Redmond, WA................................62Q3/16 Meeting Roster, July 15 – 18, 1997, Redmond, WA................................................................64

1998 Standards Committee Meeting Schedules as of August 4, 1997...........................................................64Acronym Glossary..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .651997 Standards Committee Meeting Schedules as of August 4, 1997...........................................................67

COMMUNICATIONS STANDARDS REVIEW – TELECOMMUNICATIONS

2 Vol. 8.7 Copyright © CSR 1997 July-August 1997

REPORT OF TR-30.2, DIGITAL INTERFACES, INCLUDING DTE-DCEPROTOCOLS, JUNE 13, 1997, COSTA MESA, CA

Editor’s note: The TR-30.3 report from June was not available.

This was the first meeting of TR-30.2 which included the DTE-DCE Protocol work from the former TR-30.4.

STANDARDS FOR REVIEW

TIA provided a listing of Standards (including Bulletins) and Interim Standards which required the attention of TR-30.2. A similar list provided to TR-30.1 (Modems) came from the original TR-30.1, Electrical Characteristics.

Industrial Electronics Bulletin No. 11, Fault Isolation Methods for Data Communications Systems (1972) wasdeemed to be no longer applicable; its withdrawal was recommended.

TIA/EIA-602, Data Transmission Systems and Equipment - Serial Asynchronous Automatic Dialing and Control,will be revised to become primarily a reference to ITU-T V.25ter. It will contain a listing of the V.25ter commandswhich apply to TIA/EIA-602.

TR-30.2 will reaffirm four existing standards:• EIA/TIA-530-A, High Speed 25-Position Interface for Data Terminal Equipment and Data Circuit-Terminating

Equipment, including Alternative 26-Position Connector• EIA/TIA-561, Simple 8 Position Non-Synchronous Interface between Data Terminal Equipment and Data

Circuit-Terminating Equipment Employing Serial Binary Data Interchange• EIA/TIA-562, Electrical Characteristics for an Unbalanced Digital Interface• EIA/TIA-574, 9 Position Non-Synchronous Interface between Data Terminal Equipment and Data Circuit-

Terminating Equipment Employing Serial Binary Data Interchange

New projects will be opened to reaffirm the above work.

TIA/EIA-695, C ONTROL OF VOICE FUNCTIONS

SP-3131, Voice Control for Asynchronous DCE, has been forwarded to TIA for publication as TIA/EIA-695. It isexpected to be available late summer or early fall, 1997.

In implementing TIA/EIA-695, it has been discovered that Stuttered Dial Tone event reporting should have acomplex event report rather than the simple report specified in TIA/EIA-695. TR-30.2/97-06-011 (C. Sneed,Rockwell and J. Decuir, Microsoft) explains this condition and recommends the change to the complex report. Inaddition, TR-30.2/97-06-015 (C. Sneed, Rockwell) offers some recommended clarifications of the SpecialInformation Tone (SIT) and Call Waiting plus Caller ID event reporting. TR-30.2 members felt that these changesshould be documented for inclusion in the next edition of TIA/EIA-695. The TR-30.2 Chair agreed to discuss theuse of a Technical System Bulletin (TSB) with TIA for this. In addition, the two companies indicated that they willbring the same information to the July Q7/16 Rapporteurs meeting for consideration in the V.voiceRecommendation.

TR-30.2/97-06-012 , TR-30.2/97-06-13 and TR-30.2/97-06-14 (all from C. Sneed, Rockwell and J.Decuir, Microsoft) propose the addition of new commands in support of voice duplex operation with the DCEresponsible for any necessary acoustic and line echo cancellation. TR-30.2 attendees did not fully understand the re-quirements and needs for these commands. The contributors indicated that they would bring additional contributionsto the August 1997 meeting to more clearly explain these proposed commands.

TIA/EIA-678 A NNEX D (PN-2499), WIRELESS COMMAND SET

The exact status of Annex D to TIA/EIA-678 was not available; the editor was not in attendance. At the April 1997TR-30.4 meeting, there had been a discussion of problems between TIA/EIA-615 and Annex D. The editor hadagreed to look at a resolution of the issue. This issue was left to be resolved at the August 1997 meeting.

PN-2989, EXTENDED DCE FUNCTIONS

TR-30.2/97-06-009 , AT command set for DCE controlled V.8bis negotiation (R. Miller, RSA and A. Sadri,IBM), and TR-30.2/97-06-010 , Command parameter extension for +A8E (R. Miller, RSA), are revisions ofTR-30.4/96-12-050R2 (R. Miller, RSA and A. Sadri, IBM) and TR-30.4/97-04-012R1 (R. Miller, RSA),



respectively. Although the authors were not in attendance, it was understood that the revised documents wereintended for the July Q7/16 Rapporteurs meeting in Dublin, Ireland and provided to this meeting for information.

TR-30.2/97-06-016 (J. Decuir, Microsoft) asks TR-30.2’s opinion of standardizing Modem Diagnosticcommands to report “last call” diagnostic information to the DCE. This issue had been raised at the April 1997 TR-30.4 meeting; a liaison had been sent to TR-30.1 asking their opinion on including diagnostic functions in modems.Because a response had not been received from TR-30.1, there was difficulty answering the questions raised byMicrosoft. A response may be forthcoming from TR-30.1 prior to the August 1997 TR-30.2 meeting.

REVISION OF EIA-485 (PN-3498)

TR-30.2/96-04-006R4 is the final draft of the revision of TIA/EIA-485-A, Standard for Electrical Characteristicsof Generators and Receivers for Use in Balanced Digital Multipoint Systems (PN-3498), provided by the TR-30.2.1ad hoc chairman, J. Goldie (National Semiconductor). TR-30.2 reviewed and approved the draft for ANSI Industryballot. The companion Technical System Bulletin, Application Notes for TIA/EIA-485-A (PN-3615), is not yetcomplete; however the editor indicated that he now expects it to be ready for committee letter ballot at the October1997 TR-30.2 meeting.

PN-3855, H IGH SPEED TYPE 232 DTE/DCE INTERFACE

The new standard for a High Speed Type 232 DTE/DCE interface is now out for ANSI Industry ballot as SP-3855.This ballot closes on August 4, 1997, which is prior to TR-30.2’s August 1997 meeting. Ballot comments will beaddressed at that meeting.

Fred Lucas, General Datacom

TR-30.2 MEETING ROSTER, JUNE 13, 1997, COSTA MESA, CA

F. Lucas, General Datacom TR-30.2 ChairHost: Rockwell

AMP, Inc. Ben BennettAnalog Devices Rao NuthalapatiData Race Les StaplesGeneral DataComm Fred LucasHayes David RifeLucent Technologies John MagillMicrosoft Joe Decuir

Motorola ISG Les BrownMotorola ISG Dick BrandtMultiTech Systems R.S. GopalanNational Semiconductor John GoldieRockwell Chris SneedRockwell Glen GriffithTexas Instruments Kevin Gingerich

Communications Standards Review – Telecommunicationsregularly covers the following committee meetings:

TIA TR-29TR-30TR-41

ITU-T SG 8SG 15 WP1SG 16 (formerly SG 14, with parts of SG 8 and SG15 relating to multimedia)

ETSI ATADTAMTATC SPTC STQTIPHON



REPORT OF Q12/16, Q13/16 AND Q14/16 RAPPORTEUR MEETINGS,JUNE 10 – 13, 1997, HERZLIA, ISRAEL

Referenced APC- and TD-documents in this report are available at: ftp://itu-t:sg15!avc@ftp. gctech.co.jp/9706_Her/Documents identified in this report as “-e” are available from CSR in electronic format only.

LIAISONS

March 1997 SG 16 Meet ing ReportWP1/16, WP2/16, and WP3/16 were established, their chairmen and rapporteurs were appointed; Q11(H.324) wasshifted from WP1/16 to WP2/16. Rapporteurs were urged to reduce the translation cost for revisions through thefollowing procedure:• Change marks against the previously translated version• Clean text with all the changes incorporated• Provide separate list of changes.Coordination was recommended with Q18/16 with respect to Internet Telephony through coordination amongQ13/16 (H.323), Q14/16 (H.3xx protocols) and Q18/16; joint sessions are planned in September 1997.

April 1997 IETF MeetingReal Time Transport Protocol (RTP) payload format for H.263 (Video Coding for Low Bit Rate Communication)awaits discussion of H.263+ and H.332. TD-8 (J. Ott, Teles) provides information on the Public SwitchedTelephone Network (PSTN) Internet interworking (PINT) working group. They plan to work on a Service SupportTransfer Protocol and related MIBs (Management Information Base).

April 1997 ATM Forum MeetingS. Okubo (GCL) reported: H.321 V2 (Adaption of H.320 to B-ISDN environments) and Annex C to H.323 (H.323on ATM, AAL1/AAL5 conversion procedures) were distributed for comments; H.310 Implementers Guide from theMarch SG 16 meeting was distributed for information. Comments will be returned from the July ATMF meeting,except for the addition of signaling protocol stack to Figure 43/H.323.

May 1997 Q3 /16 Meet ingJ. Ott (Teles) reported: works on text telephony for the deaf (T.chat) and T.secure are ongoing; T.120Lite wassubstantially completed; Q3/16 (T.120) will co-locate with Q13/16-Q14/16 in September 1997 in Sunriver, OR.

DAVICT. Taylor (Nortel) noted that Digital Audio-Visual Council (DAVIC) would start work on communicative services.S. Okubo (GCL) agreed to monitor the linkage with H.323.

Q12/16, B-ISDN MULTIMEDIA SYSTEMS AND TERMINALS

TD-27 is the report of the meeting from the Rapporteur S. Okubo (GCL).

H.321 VERSION 2, ADAPTION OF H.320 TO B-ISDN E NVIRONMENTS

C. Gates (First Virtual Corporation) is acting Editor of H.321 V2. APC-1209 (C. Gates, First Virtual) provideseditorial changes to the version of H.321 Determined at the SG 16 meeting in March 1997. It was noted that thewhite contribution for Decision should include change marks against the previously translated version (approvedVersion 1 in this case).

APC-1198 (Japan) presents several comments on APC-1209 . They are editorial except for one regarding namingof “Annex B/H.320 Gateway;” the name should be more generic if the gateway is common to other circuit emulationservices. The meeting agreed to incorporate the proposed changes in the next draft.

J-P. Blin (France) indicated his interest in the jitter reduction when H.321 Annex B is used, including the possibilityof submitting a contribution at a future meeting. It was noted that the “network adaptation layer (NAL)” in H.321Annex B provides jitter reduction; the same functionality is required at the Annex B/H.320 Gateway.

H.310 VERSION 2, BROADBAND AUDIOVISUAL COMMUNICATIONS SYSTEMS AND TERMINALS

K. Sakai (Fujitsu) has become the H.310 V2 editor replacing C. Gates (First Virtual).



Interworking Scenario

APC-1172 (Korea) is a copy of D.2 from SG 16. It notes that the H.310 interworking scenario should also coverthe case of uni-directional terminals and the case of the gateway being provided at the service provider or networkprovider in addition to the customer premises network. The current H.310 communication model is rather simple,without distinguishing the service provider and the terminal. The gateway at the network provider is covered in thecontext of I.580 (General arrangements for interworking between B-ISDN and 64 kbit/s based ISDN) from SG 13.

APC-1175 (Q.12 Rapporteur, S. Okubo) is a copy of TD-47(WP2/16) from the March 1997 SG 16 meeting.It summarizes the study of communication procedures when AAL1/AAL5 conversion is involved. H.321 currentlyspecifies AAL1 for the ATM adaption layer. AAL5 was added because it is widely used in the form of personalcomputers and work stations on customer premise ATM networks. APC-1175 also includes the liaison statementto SG 11 providing editorial comments on the “Correlation Identifier,” and requests the “End Station Identifier” inQ.2941.1. Discussion on this topic will be carried over to the next meeting due to the absence of interested partiesat this meeting.

Optional Stack for H.245 Message Transport

APC-1174 (Q12/16 Rapporteur) is a copy of TD-76(WP2/16) from SG 16 in March 1997. It proposes toinitiate the study of the TCP/IP stack for H.245 message transport in H.310 terminals. This has been raised in theinterest of:• Interworking with H.323 etc.• Next generation system, as discussed in APC-1197 (see below under Q13/16, New Topics).

H.320/H.321 Interoperat ion Mode of H.310 RAST-5

APC-1200 (Japan) discusses a compatibility problem. H.321 V2 was Determined at the SG 16 meeting in March1997 where an AAL5-based protocol stack was defined as Annex B. Since this had to be different from theH.320/H.321 interoperation mode stack of H.310 RAST-5 (Figures 1 and 2), these two terminals (H.310 RAST-5and Annex B/H.321) cannot directly communicate with each other even if they are both on the same customerpremise network. APC-1200 provides some possible solutions. One is to change H.310 specifications. It wasnoted that this might be possible if there were no companies with products based on the existing specification.Position papers are solicited. In the meantime, the Rapporteur will consult with SG 16 management regardingpossible replacement procedures.

Security Aspects

APC-1202 (Japan) discusses a possible H.310 encryption arrangement, utilizing H.262, MPEG 1/2 Audio, andH.222.0 to support harmonization with the existing broadcast conditional access system. I. Sebestyen (Siemens)suggested that the security requirements should first be formulated since H.310 security operation may differdepending on the application. It was also recognized that harmonization with H.235 (H.secure) is required.

Init ial Draft

The editor will create an initial draft taking into account:• H.310 Implementers Guide• Intercommunication between AAL1 and AAL5 terminals• Intercommunication with telephone and other H-series terminals (under study)• Review of H.320/H.321 interoperation mode of RAST-5• Optional H.245 transport stack

H.BMULTIPOINT

H. Harasaki (NEC) is the H.bmultipoint editor. He will issue an initial outline draft before the next meeting so thatthe contents can be filled in based on contributions.

APC-1201 (Japan) is draft Recommendation H.bmultipoint. APC-1201 discusses the framework of broadbandmultipoint systems by listing requirements, applications, four types of multipoint configurations (multi-point,broadcast, panel with audience, lecture), call setup procedures, audiovisual signal processing in Multi-point ControlUnit (MCU) and conference control. The meeting felt the contribution to be a good start.

There was some discussion on the scope of this Recommendation. D. Lindbergh (PictureTel) asked whether thiscould be generalized to cover all H.245-based MCUs to avoid different architectures in H.310, H.323 and H.324 sys-tems. It was pointed out that H.323 already includes multipoint aspects, and that the resource available for this



Asynchronous Transfer Mode (ATM) work is limited. Q12/16 concluded that H.bmultipoint should utilize theH.323 work as much as possible and focus on the ATM-specific features such as use of ATM multicast, audiovisualsignal processing at MCU. See the Q14/16 report below, for additional information.

ANNEX C TO H.323 (H.323 ON ATM)

See the Q13/16 report, below.

Q13/16, PACKET-SWITCHED MULTIMEDIA SYSTEMS AND TERMINALS

TD-26R is the report of the meeting from D. Skran (Ascend), the Rapporteur.

H.323/H.225.0 V1 I MPLEMENTERS GUIDE

APC-1245 (P. Long, Smith Micro Software) notes that some confusion exists about the use of spatial/temporaltrade-off signaling. See below for additional details. This contribution is a candidate for inclusion in the H.323 V1implementers guide.

It was agreed that the widely used, current H.263 (low bit rate video coding) packetization that is being included inH.225.0 V2 (H.263 video packetization) should also be added to the H.323 V1 implementers guide. This is not thesame as the H.263 packetization currently under development in the IETF; that will be added only to H.225.0 V2under a new code point “h263a.” See APC-1189 below, under “Video.”

H.323 V2, PACKET-BASED MULTIMEDIA COMMUNICATIONS SYSTEMS

APC-1210-e (G. Thom, Delta Information Systems) is the current draft of H.323 V2. All changes made in theSG 16 meeting are reflected; there were no additional comments.

APC-1190 (J. Toga, Intel) proposes some changes to H.323 sec 8.3.4 (Correlation of Media Streams inMultipoint Conferences) and H.225 sec 6.2.2. It was agreed that the changes are needed, but some clarification isnecessary concerning cascading. TD-38 (G. Freundlich, Lucent; V. Kumar, Intel; M. Reid, PictureTel) proposes toadd a “source” field to the OpenLogicalChannel message.

APC-1205 (M. Reid and K. Hedayat, PictureTel) comments on H.323:

• Item 2.2: substitute Conference Identification (CID) is a problem for the Gatekeeper. Currently the substituteCID command does not address what happens on the RAS channel. This will be reviewed at the next meeting.

• Item 2.3: some Call Reference Value (CRV) clarification was agreed; modified text will be provided to theEditor.

• Item 2.4: an inconsistency between multipointModeCommand and multipointConference was agreed; it was leftto the Editor to try to resolve inconsistency between H.323 8.3.5 and 8.4.3 note C3.

• Item 2.5: M. Reid (PictureTel) will work with the Editor to incorporate an Ad Hoc Multipoint clarification.• Item 2.6: corrections to Annex A were accepted.• Item 2.7: additional editorial changes were accepted.

APC-1207 (A. Shemi, RADVision) raises three issues:

• Item 1 proposes using IRR (Information Request Response) for keep-alive in the Radio Control Function (RCF)message. It was stated that this may conflict with time to live (TTL) operations, and it may be unnecessary. Seealso APC-1221 below. It was agreed to use an alternative based on the RRQ (Registration Request) messageand a slightly modified version of the existing TTL. The results appear in TD-11 (O. Kahane, VocalTec; A.Shemi, RADVision; and G. Freundlich, Lucent).

• Item 2 points out possible confusion of vendor ID in the RRQ message. It was agreed that Editor will clarify theconfusion in H.225.0 V2.

• Item 3 proposes adding message direction in the Call ID; instead it was decided to add sender/receiver bits(answerCall) to the Bandwidth Request (BRQ)/Disengage Request (DRQ) similar to those in the AutomaticRepeat Request (ARQ), as described in TD-16 (A. Shemi, RADVision).

APC-1215 (BT) contains a proposal for overlap sending in H.323 (as opposed to enbloc). Overlap sending is aconvenient dialing method when either a telephone or a PC keyboard is being used. When insufficient dialinginformation is available in the SETUP message, the network sends back SETUP ACK which indicates thatadditional dialing information may be required. Additional dialing information is transferred to the network using the



Q.931 INFORMATION message. When sufficient dialing information is available, CALL PROCEEDING is sent.The editors will incorporate this optional procedure, with some clarifications.

APC-1218 (C. Fleiner and H. Linh, IBM) proposes to clarify H.323, Section 8.4.3.1, Direct Endpoint CallSignaling - Conference Create, on ad-hoc conferencing. This was discussed but not fully agreed. It will bedeveloped further.

APC-1221 (G. Freundlich, Lucent) makes various proposals related to H.323:

• Item 1 is a similar proposal to APC-1207 above (A. Shemi, RADVision) Item 1; see also TD-11 (O. Kahane,VocalTec; A. Shemi, RADVision; and G. Freundlich, Lucent).

• Item 2 is a proposal for logical channel control changes for more efficient use of MC resources. This wasaccepted.

• Item 3 proposes changes to UserInputIndication to support duration of Dual Tone Multi Frequency (DTMF) tonesand a terminal label of a destination. The duration issue is discussed in APC-1234 (T. Nixon, Microsoft). Itwas agreed that clarification of the multipoint operation of UserInputIndication is required, but that this proposalneeds further work, such as adding capabilities, extending labels to other messages, etc.; it will be furtherdeveloped for September 1997.

APC-1231 (I. Sebestyen, Siemens) proposes to remove text describing which low-bit rate coder should be used inH.323 V2 (G.723.1 or G.729), as agreed at the March 1997 meeting. Siemens no longer supports the compromiseof H.323 V2 section 6.2.5.3, noting that the IMTC has voted in favor of using G.723.1 only. He raised the concernthat with the IMTC, and presumably industry, using the G.723.1 codec only, it damages the ITU-T reputation tosupport two codecs. It was decided to defer action until the Study Group meeting due to controversy surrounding theproposal.

APC-1245 (P. Long, Smith Micro Software) is an informational paper on temporal/spatial tradeoff interoperabilityproblems. It describes concerns with the interpretation of this capability and suggests that it is confusing and shouldonly be used in the OpenLogicalChannel request. The contribution was viewed to be important and clarification isnecessary. The contribution will be a V1 Implementers Guide candidate. Q11/16 Rapporteur T. Geary (Rockwell)will carry APC-1245 to the next Q11/16 meeting.

TD-34 (G. Thom, Editor H.323) shows all agreed changes to H.323. The changes from APC-1190 (J. Toga,Intel) and APC-1205 (M. Reid and K. Hedayat, PictureTel) are contained in TD-38 (G. Fruendlich, Lucent; V.Kumar, Intel; M. Reid, PictureTel). The changes from APC-1207 (A. Shemi, RADVision) and APC-1221 (G.Freundlich, Lucent) in TD-34 will be removed in deference to those of TD-11 (O. Kahane, VocalTec; A. Shemi,RADVision; G. Freundlich, Lucent).

DTMF Related

APC-1213 (P. Long, Smith Micro Software) is a proposal to add A, B, C, D (DTMF signals) toUserInputIndication. These tones are apparently used for coding of priority in military telephone systems. It wasdecided to not change the existing text as it would create interoperability issues, and to defer to September or V3,based on more explanation. This may also be worked as part of H.246. It was mentioned that there are others waysto send A, B, C, D as tones. These tones may be part of the new DTMF system being developed; see APC-1234(T. Nixon, Microsoft), below.

APC-1221 (G. Freundlich, Lucent) proposes adding duration to UserInputIndication. APC-1234 (T. Nixon,Microsoft) contains a set of proposals on carrying DTMF on H.323 systems. The choices seemed to be:

• In-band using toll quality coder• Encoding DTMF as a special RTP payload• Extended H.245 UserInputIndication

APC-1234 will be developed further on the reflector with regard to H.245 UserInputIndication. Consensus wasnot achieved on what should be the baseline method, H.245 or RTP payloads.

TD-7 (P. Long, Smith Micro Software) is a response to APC-1234 (T. Nixon, Microsoft); it requests thatexisting UserInputIndication not be changed. It was agreed that the startTone/stopTone/continueTone method forH.245 might be developed further.



Faster Call Setup

APC-1187 (J. Toga, Intel) is a proposal with consolidated H.245/Q.931 signaling that allows for much faster callsetup, while retaining commonality with the baseline H.323 terminal.

APC-1193 (BT) proposes various small changes to speed up call setup such as shorter retry timers.

APC-1239 (J. Ott, Teles) is a proposal for capability-negotiation-less quick call setup.

APC-1247 (G. Freundlich, Lucent) proposes uses existing messages and procedures to speed up call setup.

After a discussion of the various proposals, each of which was felt to have significant merit, a set of guidelines wasagreed:

1) There will be no change to baseline H.323 (i.e., no H.245-less systems).2) The work will focus on producing a result for Version 2 of H.323/H.225.0.3) The work will minimize changes.4) The goal will be to minimize cut-thru time, connect time, and setup time.5) Capability negotiations must be part of the solutions from the start.6) Ideas from APC-1193 and APC-1247 will be added as H.323 text with consideration given to supplementary

services, including Security and fast cut-thru.7) APC-1187 and APC-1239 will be the basis of on-going work for September 1997.

QOS Related

APC-1182 , APC-1183 , and APC-1184 (all from Cisco Systems), discuss H.323 Version 2, H.225 Version 2changes and H.245 Version 3 changes respectively. Together the three contributions comprise a completely newproposal on QoS control using Resource Reservation Protocol (RSVP); it uses mainly Determined material.Various syntax issues were remanded to the editors of H.245/H.225.0/H.323. APC-1182 was split into an H.323part and an H.225.0 part; examples of RSVP for G.711 will be added to the appropriate H.225.0 appendix. TD-14(H. Salama, Cisco Systems) describes an extension of APC-1183 on a per call basis; this was accepted. TD-15(H. Salama) describes changes to APC-1184 that were agreed at the meeting on H.245 related to Quality of Service(QOS) management.

APC-1203 (Japan) proposes that a clear communications procedure using RSVP should be described in H.323. Itincludes various concerns with RSVP. It also notes that one can re-signal logical channel parameters when thereservation fails and then use a BRQ (Bandwidth Request). This text and other requested clarifications will be added.

APC-1211 and APC-1212 (both from P. Long, Smith Micro Software) contain a media-independent proposal fora redundancy method involving the logical X-OR function of packets. TD-6 (T. Nixon, Microsoft) argues againstthe approach of APC-1211 and APC-1212 . The scheme was rejected due in part to long latency when packetswere lost; it was agreed to not pursue this method further. It was noted that H.263+ has very nice packet lossrecovery techniques. It was also noted that error correction should be below encryption in the stack.

APC-1227 (M. van Dort and J. de Muijnck, KPN) proposes a liaison to Q3/16 on T.RES and RSVP. It wasdecided that no liaison will be sent; the use of T.RES to control RSVP does not appear to be the correct approach.

H.225.0 V2, MEDIA STREAM PACKETIZATION

APC-1219-e (G. Freundlich, Lucent) is the draft of H.225.0 Version 2.

APC-1180 (K. Klaghofer, Siemens) proposes changes to H.225.0 to align it with the new H.450.x (GenericFunctional Protocol, QSIG) recommendations. It was accepted with some small changes.

APC-1190 (J. Toga, Intel) proposes editorial clarifications to H.225.0 V2. The changes proposed for sec. 6.2.2(video messages) were accepted. The changes to section 12.3.1 (usage of RTP) were accepted with the addition of thephrase “of the same video picture.”

APC-1205 (M. Reid and K. Hedayat, PictureTel) provides comment on H.225 sec. 8.3.10, Destination address inthe setup message. It was accepted with the amendment that when dialing a destination address other than a transportaddress, the destination address shall be included.

APC-1207 (A. Shemi, RADVision) proposes adding originator/sender information on Registration, Admission andStatus (RAS) messages. The amended text is in TD-16 (A. Shemi, RADVision) which follows the methodcurrently used in Automatic Repeat Request (ARQ). The proposal will be added to H.225.0.



APC-1223 (G. Kajos, VideoServer) is a proposal for a conference alias. This alias needs to properly relate toT.130/120 and T.124. The revised version in TD-23 (G. Kajos, VideoServer) was not agreed. On-going workmust cover H.243 interworking, GW (GateWay) to phone, GW to H.323 scenarios, and the mapping of the alias toCID.

APC-1224 (G. Kajos, VideoServer) is a proposal to use SETUP to request a list of available H.323 conferences.It was agreed that the proposal needs to be enhanced along the lines of similar T.124 similar messages. It was notedthat ConferenceAlias should not be a SEQUENCE, just a BMP (bit-mapped) string. Some suggested that thismight be formulated as a new service, but others said that SETUP must have some indication in any case. Theproposal was developed in TD-23 (G. Kajos, VideoServer), but was not agreed.

APC-1225 (G. Kajos, VideoServer) proposes a canonical text representation of the CID. the proposal waswithdrawn. It was agreed that the current text in H.225.0 V2 will be updated to add the current method for textdisplay of CID, which was not fully documented.

APC-1228 , Proposed H.225.0 Modifications for Identifying Source Aliases Over Multiple Call Legs (R. Baird,Cisco Systems) was withdrawn, as it was clarified that source address is always the original source regardless ofhowever many gatekeepers are involved.

APC-1229 (R. Baird, Cisco Systems and S. Petrack, VocalTec) proposes a new format for DNS TXT (DomainName Server, text) records that is more compact. The proposal was accepted; a slightly modified text will beforwarded to the editor.

APC-1230 (R. Baird, Cisco Systems and S. Petrack, VocalTec) provides some additional details about using DNSto find a gatekeeper during Admission Request (ARQ) and Location request (LRQ) operations. The contribution wasaccepted.

TD-30 (S. Petrack, VocalTec) proposes adding a reason in Unregistration Request (URQ), and also to requireendpoints as well as Gatekeepers (GKs) to send Unregistration Confirm (UCF). The second point is covered by thecurrent text. The editors will give consideration to this proposal.

H.323.0 ANNEX B, PROCEDURES FOR LAYERED VIDEO CODING

APC-1196 (G. Kisor, Intel) is a draft of Annex B, Layered Video Coding. Some minor changes were suggested.It was agreed that the text will be moved into H.323.

APC-1204 (Japan) is a proposal for using RSVP for layered video using multi-layer dependency. The proposalwas rejected as multi-layer dependency is not allowed in H.263+. Some text will be added to the Annex B to indicatefor which layers RSVP should be used.

H.323.0 ANNEX C, H.323 ON ATM

APC-1195 (G. Kisor, Intel) is the draft Annex C, H.323 on Asynchronous Transfer Mode (ATM). Variouschanges to remove ATM Forum terminology were made. It was requested and agreed that Internet terminology willbe made consistent with the rest of H.323. It was also agreed that the call control requirement for ATM will bemade more clear.

APC-1199 (Japan) provides ITU-T QOS type definitions. The Editor (G. Kisor, Intel) expressed his thanks forthis contribution, which will be incorporated into Annex C. It was mentioned that the semantics for ATMParams inH.245 were insufficient and not very clear; more text will be added to H.245 along with references to Annex C.

APC-1217 (H. Linh, IBM) proposes using uni-directional rather than bi-directional channels for Annex C. Bothmethods will be required in Annex C. New text will indicate that uni-directional is best for multipoint and bi-directional for public ATM with per-Virtual Container (VC) billing.

H.225.0 NEW PACKETIZATIONS

Audio

APC-1220 (G. Freundlich, Lucent) proposes a G.729 packetization that aligns with IETF RFC 1890 (draft-ietf-avt-profile-new-01). The major technical change is to allow only one silence frame per packet so that packet sizeindicates whether the packet contains a silence frame or not. Questions were raised about the potential instability of



the IETF activities, but it appears that this problem will be resolved by September 1997. Language will be added toindicate that receivers must handle 1-20 frames per packet; other references will be removed to avoid confusion.

APC-1232 (S. Petrack, VocalTec) proposes that a code point be added for a Global System for MobileCommunications (GSM) codec in H.245 to avoid transcoding in conversion to mobile phones. This issue will bedeferred to September 1997. A letter will be sent informally to ITU-R asking advice.

TD-9 (P. Coverdale, SG 12) is a letter from SG 12 to SG 16 welcoming collaboration on the Speech Qualityaspects of Internet telephony; it notes their concerns regarding the delay and voice quality of G.723.1 wheninterconnected to the PSTN. TD-29 (Q13/16 Rapporteur) is the response.

Video

APC-1173 (Q11/16, Q12/16, Q13/16, Q14/16 and Q15/16 Rapporteurs) describes the methodology of futurecoordination (communications and co-located meetings) on video coding.

APC-1189 (J. Toga, Intel) supports two packetizations for H.263, one that corresponds to the current codepointand current practice, and another for the h263a codepoint that follows the IETF H.263 packetization. APC-1205(M. Reid and K. Hedayat, PictureTel) supports APC-1189 (J. Toga, Intel). APC-1236 (S. Wenger, Teles) alsosupports APC-1189 (J. Toga, Intel), but wants to see “old” or baseline in the implementer’s guide rather than inthe standard. This viewpoint was not approved.

APC-1237 (S. Wenger, Teles) describes a Real Time Transport Protocol (RTP) payload format for H.263+ tosupport video redundancy coding. This will be considered for H.245 version 3.

The general conclusion was to include both payload formats as per APC-1189 (J. Toga, Intel), and also to add thecurrent packetization to the version 1 implementer’s guide.

APC-1238 (J. Ott, Teles) extends audio redundancy coding to video redundancy and shows the extensions to H.245for this purpose, but only applies to H.263+ using H.263 Annex N (Reference Frames) without back channel (whichis proposed for H.245 V3 in APC-1237). This proposal was accepted. Procedures for H.323 need to be suppliedin September for this extension to occur.

TD-12 (S. Wenger, Teles) is a proposal for a liaison to request advice from Q15/16 as to how to negotiate the 15additional modes of H.263+ in H.323 systems. TD-28 (Q12/16 Rapporteur) contains a proposed liaison. Therewere many suggestions for changes, including preventing specific combinations of modes, multipoint not alwaysbeing continuous presence, etc. TD-37 (S. Wenger, Teles) is the approved liaison which requests that Q15/16develop profiles.

H.332, FORMER H.LOOSELY -COUPLED

APC-1186 (V. Kumar, Intel), is draft H.332. It describes how loosely-coupled conferencing is done within thescope of H.323. Loosely-coupled conferencing refers to potentially large numbers of essentially receive onlyterminals “loosely-coupled” to an H.323 conference via RTP/RTCP. A note explaining the format of Figure 3(Format of the SDES item address) will be added. TD-18 (V. Kumar, Intel) contains the agreed changes.

APC-1182 (Cisco Systems) provides the general proposal for resource reservation in H.323. APC-1185 (CiscoSystems) describes QOS control using RSVP in H.323. This document only addresses resource reservation forH.332 terminals using RSVP. The contribution will be added as an appendix to H.332. TD-21 (Cisco Systems)contains revised text to be added to H.323 V2.

H.450.1, GENERIC FUNCTIONAL PROTOCOL, I.E., QSIG

APC-1177 (M. Korpi, Siemens) is the draft Generic Functional Protocol for support of supplementary services inH.323. The following changes were agreed:• Gatekeeper and calling rules for the non-call associated call will be added.• In section 8.1 (network facility extension), a description of how a gatekeeper and the terminating endpoint can

participate in the service will be added.

APC-1205 (M. Reid and K. Hedayat, PictureTel) section 4.1.1 proposes for H.323 and H.225 a new conferencegoal in the SETUP message for call-independent transport of H.450.1 supplementary services. This would be codedon both the Q.931 and user-to-user level. This change was added with the suggestion of the name, “call independentsupplementary service.”



TD-13 (S. Ruditsky and A. Shemi, RADVision) proposes to use a simplified ASN.1 that does not use AbstractSymbol Notation (ASN) Object Classes as in X.880 (Remote Operations: concepts, model and notation), whichincrease the complexity of the ASN.1 compiler needed for H.323. It was mentioned that the current direction may bethe first usage of PER (packed encoding rules), Remote Operations Service Element (ROSE), and ROSE Classes inany standard. Concern was expressed about whether compilers currently support such usage; investigation will beconducted.

It was also feared that the current direction might result in a large burden on a gateway transcoding between thepublic network and H.323. There was support for simplification, with the idea that TD-13 would be furtherdeveloped, with separate trees for each service; it is expected that the result would be reviewed in September 1997.

Q13/16 Rapporteur D. Skran issued a warning that if the H.450.x series was not sufficiently mature, no whitepaper(s) would be issued, as was specifically noted in the SG 16 meeting report.

H.450.2, CALL TRANSFER SUPPLEMENTARY SERVICE

APC-1178-e is the draft Call Transfer supplementary service. Several changes were agreed, including: In section10.5.1 (Gatekeeper actions), the gatekeeper can provide the service and need not transparently send informationelements. In section 10.5 (Interactions with H.323 Ad Hoc Conference), conferenceGoal = join should beconferenceGoal = invite in the example. Additional examples are to be added.

APC-1205 (M. Reid and K. Hedayat, PictureTel) proposes the following:

• Section 4.2.1, Release of the secondary call, proposes that the release of the secondary call be optional in certaincases; this was rejected in favor of clarifying the current text.

• Section 4.2.2, Transferred to endpoint should clear the secondary call, was accepted.

APC-1222 (G. Freundlich, Lucent) proposes adding to section 1 a discussion of call transfer for the gatekeeperrouted model, with discussed changes.

H.450.3, CALL DIVERSION SUPPLEMENTARY SERVICE FOR H.323

APC-1179-e is the draft on call diversion. The issue of including authentication in H.450.3 was raised as it coulddelay H.450.3. The issue will be considered further.

APC-1205 (M. Reid and K. Hedayat, PictureTel) in section 4.3.1 proposes small editorial changes to H.450.3,which were accepted.

APC-1222 (G. Freundlich, Lucent) proposes the following:• Item 2, Assigning diversion information in the GK, is a reasonable proposal.• Item 3 proposes to use DivertingLegInformation1 as notification to passive parties in call diversion.• Item 4 proposes adding additional information in diversion operations.

The items in APC-1222 are clarified in TD-35 (G. Freundlich, Lucent), which was put forward to H.450.3 forinclusion. Detailed review is solicited.

NEW TOPICS

H.323 V2 added a profile in Annex C to support the audio and video streams over RTP. The IP connection is usedto establish the call and bring up control (H.245). APC-1197 (G. Kisor, Intel) proposes a new method for H.323V3 which would support audio and video on separate connections (e.g., PSTN/ISDN) as well as ATM. This has theadvantage of one network (IP) for the control of different connections. Intel proposes this to address the concerns oforganizations about the burden of audio/video media traffic on their LANs. Various views, pro and con, wereexpressed. The proposal is a possible model for future work, but not the only one.

APC-1214 (R. Callaghan, Siemens) is a proposal for a new service “Transparent Transport of Switched CircuitNetwork Information.” It is directed toward 1998 Determination.

APC-1216a (P. Cordell, BT) proposes a framework for Inter-GK communications. It is directed toward 1998Determination. Comments are invited.

APC-1233 (D. Lindbergh, PictureTel) is an H.245 “replacementFor” proposal which allows for more rapidswitching of modes using H.245; see the H.245 report below, under Q14/16.



APC-1240 (J. Ott, Teles) discusses Dynamic IP addresses, consideres various cases in which IP addresses mightchange during a call, and suggests four methods on how this might be handled, including two for further considera-tion. The contribution will be studied further.

TD-25 (W. Erikson, Ericsson) calls for the use of the “+” sign in the dial string for E.164 addresses, whichtypically means “international call.” Since the proposal is already supported in another way, the contribution wasnot approved at this time.

SUPPLEMENTARY SERVICES

APC-1226 (N. Perinpanathan, Nortel) provides procedures for terminal mobility defined in APC-1171 andsupports terminal mobility when there is no GK. Various issues related to security and a lack of support for the GKrouted call model were mentioned. Several members raised the issue that the GK solved this problem, and that theneed for this feature was unclear. There also appeared to be procedural duplication with existing GK operations.

APC-1171 , Terminal mobility as an H.323 supplementary service (T. Taylor, Nortel), was supplanted by APC-1216a , A framework for inter-gatekeeper communications (P. Cordell, BT). This proposes that all communicationsbetween two gatekeepers may be carried over a single TCP link and proposes the required additions to H.225 andH.323.

Q14/16, COMMON PROTOCOLS, MCUS AND PROTOCOLS FOR INTERWORKING WITH H.3XXTERMINALS

TD-21R1 is the Q14/16 meeting report from G. Thom (Delta Information Systems), Rapporteur.

SECURITY - H.235

APC-1191-e (J. Toga, Intel) is the current version of H.235. It reflects changes from the SG 16 meeting inMarch 1997. Internet Assigned Number Authority (IANA) assigned port number 1300 for the TLS (Transport LevelSecurity) port. Issues discussed include:

• The authentication protocols defined in H.235 do not conform to ISO-9798 or X.509 protocols and may containweaknesses that have these standards have overcome.

• There was a concern with Crypto-synchronization in terms of delayed packets. However, the group decided thatthe procedure is acceptable as described. D. Lindbergh (PictureTel) and J. Toga (Intel) will review the crypto-syncflag and its H.324 implications.

• It was agreed that the rekeying mechanism: rekey after 2b/2 blocks, should be removed and left to a securitypolicy.

• Escrow data allows eavesdropping. This may be required by national policy.

The initialization vector for the H.245 encryption key is sent in the RTP header. Although some people thoughtthat the initialization vector should be secret, it is not necessary and may be public.

APC-1242 (J. Wilson and J. Toga, Intel) is a clarification specifying the use of mandatory encryption algorithms.It recommends negotiation of encryption algorithms, or at least, an indication of which algorithm is being used.

The password truncation method requires further evaluation to determine if it is secure. It was determined that thiscan be extended to per call authentication. Light weight authentication procedures can be negotiated. They shoulduse standard algorithms.

TD-10 (O. Kahane, VocalTec) presents an endpoint-to-gatekeeper authentication procedure that has replay attackprotection, minimal network round-trips and no known export license or IPR issues.

APC-1176 (M. Euchner, Siemens), discusses Registration, Admission and Status (RAS) Channel Integrity; itproposes improved protection of the RAS messages. It does not provide for encryption of RAS messages. It cannotuse macro methods because it encapsulates the RAS message. Whether it is necessary only to include the signatureor to include the algorithm indication in the signature remains open and requires further work.

APC-1181 (J. Wilson, Intel), discusses Firewall Operation, including problems with H.235 when dealing withfirewalls and certificate usability. Issues raised in discussion include:

• In a multipoint case, certificates may be signed by the master.



• Challenge-Response protocol: Standard authentication protocols (ISO) were recommended. APC-1181 proposes2 message protocol (compatible with H.245 command-response) instead of standard 3 message protocol. It maybe possible to use two H.245 command-response pairs. ISO also has 2 message protocol.

• Not clear how signature is derived from the challenge. Standard authentication protocols (ISO) wererecommended.

• ISO key management and distribution was recommended.

These were discussed off line; TD-36 is the edited version, supporting X.509, ISO 9798-2 and ISO 9594-8. TheH.245 changes proposed need to be synchronized between APC-1191 (J. Toga, Intel), APC-1181 (J. Wilson,Intel), and H.245.

APC-1187 (J. Toga, Intel) discusses Fast Connect Sequence for H.323, including security procedures for the fastconnect procedure. Can this procedure be brought in line with the normal procedure? Or should H.245 negotiationbe required for security? Public key technology may not be appropriate for all applications, so other technologiesshould not be prevented. This issue will be resolved in the updated fast connect procedure.

APC-1194 (B. DeGrasse, Q3/16 Rapporteur) is a contribution from Q3/16 on T.120 security efforts. Thiscontribution includes early work on T.Secure. Why are both H.235 and T.Secure necessary? T.120 Multi-pointControl Services (MCS) is above the transport level, so it may not be able to use transport level security. A jointmeeting was agreed between H.235 and T.Secure experts at the September 1997 Rapporteurs meeting in Sunriver,OR. This meeting should not delay the H.235 schedule.

APC-1202 (Japan) describes security needs for some H.310 configurations. The H.310 group will develop asecurity requirements document which covers all H.310 configurations. This document will be used to determinewhether H.235 can be adapted to any of the H.310 configurations.

H.245, CONTROL PROTOCOL

APC-1192-e is the draft text for H.245. All changes identified for H.245 will be collected in a single documentby the Associate Editor for H.323 changes.

ASN.1

APC-1243 , APC-1244 and APC-1246 (all from P. Long, Smith Micro Software) collectively proposeconstraining H.245 ASN.1 components. Discussion yielded the following agreements:

• Change unconstrained to constrained components.• Change H.245 extension procedures to recommend constrained components.• Add text on empty sets/sequences versus missing sets/sequences.

RSVP

APC-1184 (Cisco Systems), proposes modifications to H.245 V3 signaling to accommodate ResourceReservation Protocol (RSVP). The result of the discussions, modifications to H.245 V3 to permit efficienttransport level QoS control, are summarized in TD-15 (H. Salama, Cisco Systems).

RTP

APC-1212 (P. Long, Smith Micro Software), proposed extensions to the H.245 ASN.1 syntax in support ofmedia-independent error correction using RTP, was not accepted.

DTMF

APC-1213 (P. Long, Smith Micro Software) and APC-1234 (T. Nixon, Microsoft), discussing Dual Tone MultiFrequency, require further work, to be led by T. Nixon (Microsoft).

GSM Codec

APC-1232 (S. Petrack, VocalTec) recommends an H.245 codepoint for GSM audio. RTP format for GSM doesexist and is stable. The group discussed whether an ETSI standard can be referenced in an ITU document. This issuewill be investigated with the SG 16 management and further discussion will be deferred until the September meeting.Experts agreed that it was desirable to add a GSM codepoint. I. Sebestyen (Siemens) will obtain a clarification ofthe procedure.



It was agreed to accept the proposal to add an optional parameter for OpenLogicalChannel: replacementFor, to avoidmedia dropout when switching between media (e.g., voice coders) in APC-1233 (D. Lindbergh, PictureTel). Thiswill replace H.323 Appendix B (describes audio mode change procedure), and requires the appropriate changes inH.245.

H.246, INTERWORKING

APC-1206 (M. Reid, PictureTel) is draft Recommendation H.246, Interworking. The title was changed to:Interworking of H.Series multimedia terminals, and H.Series multimedia terminals and voice only terminals on theGSTN and ISDN. The document was reviewed; the editor will incorporate the results of the discussions, asappropriate. The editor will work with interested parties in expanding the informative information.

Submissions on mandatory requirements for gateways to support inward and outward dialing are requested for theSeptember meeting.

The Rapporteur will ask Q15/16 about studying low delay video transcoding and rate adaptation (and audio also).

S. Petrack (VocalTec) will aid in the development of Annex B PSTN interoperability.

H.MEDIAMIB

APC-1208 (R. Webber, PictureTel) is a progress report on the H.MediaMIB work and includes the current draft ofH.MediaMIB. It is a first draft, and needs to be reviewed by those interested in Management Information Bases(MIBs) for controlling multimedia terminals. The main remaining tasks for this project, after adoption of the currentdraft, are definition of the full set of variables, consensus on their meaning, time constraints for their updating on thesystem being managed, and the generation and verification of actual code.

T.130 AVC SUITE

The T.130 suite of recommendations define generic mechanisms for the control and management of the audio andvideo components of a teleconference. APC-1235 (J. Boucher, BT) is the draft of T.132. T.132 is the coredocument and contains the AVC service and protocol definitions. T.132 is proposed as a T.120 application protocol;it utilizes the T.120 infrastructure recommendations MCS (T.125) and GCC (T.124). A special T.120 profileknown as T.Lite has been developed for use with T.132 to reduce the protocol burden for audio or AV onlyterminals, which do not need any of the data conferencing applications. This is expected to more than halve theoverhead associated with MCS and GCC. APC-1248 (B. Pulito, DataBeam) is a draft of T.120Lite.

TD-24 (VideoServer) discusses the issue of H.323 and its relationship with T.120/T.130. VideoServer suggestsadding functions to H.225 to support necessary features until there is better alignment. The good overview of theissues regarding use of T.130 over an H.245 logical channel are presented in TD-31 (G. Kisor, Intel). TD-31proposes a new profile for T.130. It would have a transport interface that would have the path defined in the H.245OpenLogicalChannel command. This approach does require additions to the existing H.245 and AV terminal designand would have some duplication of existing T.120 services in H.245 (e.g., routing and feature roster mechanisms).An informal ad hoc meeting of T.120 and H.323 experts was proposed to discuss the technical aspects of T.130 overH.245 logical channels. Editor’s note: See the report of this informal meeting in this issue of CSR-T (IMTCmeeting, July 8-10).

MULTIPOINT

APC-1201 (Japan) is draft Recommendation H.bmultipoint. Q14/16 agreed that H.bmultipoint should concentrateon ATM-specific features used in multipoint. A common multipoint capability between different terminal typesshould be sought. This capability may have different physical or logical implementations in the different H.3xxterminal types. Also see the Q12/16 report above. Work continues on H.bmultipoint.



Q12/16, Q13/16,-Q14/16 R APPORTEUR MEETING ROSTER, JUNE 10 – 13, 1997, H ERZLIA,ISRAEL

Sakae Okubo, GCL, Japan Q12/16 RapporteurDale Skran, Ascend, US Q13/16 RapporteurGary Thom, Delta Information Systems, US Q14/16 RapporteurHosts: RADVision and VocalTec Communications Ltd.

CanadaNortel Nishant PerinpanathanNortel Tom Taylor

FranceFrance Telecom Jean-Pierre BlinFrance Telecom Isabelle Haiqnere

GermanySiemens Robert CallaghanSiemens Martin EuchnerSiemens Eli JacobiSiemens Karl KlaghoferSiemens Istvan SebestyenTeles Joerg OttTeles Stephan Wenger

IsraelAccord Roni EvenDialogic Nimrod MullerNetXchange Jack MorgensteinNetXchange Bibi RosenbachNetXchange Roman TiefRADVision Ami AmirRADVision Sasha RuditskyRADVision Amotz ShemiVDOnet Corp. Amir StormVocalTec Alon CohenVocalTec Amir FishVocalTec Opher KahaneVocalTec Gur KimchiVocalTec Lior MoscovichVocalTec Scott PetrackVocalTec Aharon SattVocalTec Oren ShmelevichVocalTec Dror Tirosh

JapanGCL Sakae OkuboNEC Corporation Hidenobu HarasakiToshiba Corp. Eizo Fujisawa

NetherlandsKPN Mascha van DortKPN Jeroen de Muijnck

SwedenEricsson Nyrud DagEricsson Anders SvennevikEricsson Eriksen Werner

SwitzerlandIBM H. Linh Truong

UKBT Labs John BoucherBT Labs Pete Cordell

USA3COM/US Robotics Ming-Whei-Feng8*8 Hardish SinghAscend Dale SkranCisco Systems Thu DaoCisco Systems Bruce ThompsonDataBeam Bill QuinnDelta Inf.o Systems Gary ThomIntel Greg KisorIntel Vineet KumarIntel John H. WilsonLucent Glen FreundlichMicrosoft Toby NixonPictureTel Kaynam HedayatPictureTel David LindberghPictureTel Mark ReidRockwell Tom GearyVideoServer George Kajos

THE CSR LIBRARY

Subscribers may order copies of documents shown in boldface typefrom Communications Standards Review, where not controlled.-e means we have electronic copy only; +e means we have electronicand hard copy available. We have a large library of standards work in process and can helpyou locate other information you may need.



REPORT OF ETSI TECHNICAL COMMITTEE/SPEECH PROCESSING,TRANSMISSION, AND QUALITY ASPECTS (TC/STQ)JUNE 23 – 24, 1997, SOPHIA ANTIPOLIS, FRANCE

According to Chairman Perrichon, the ETSI (European Telecommunications Standards Institute) TechnicalCommittee on Speech Processing, Transmission, and Quality Aspects (TC/STQ) will not deal with speechprocessing and will concentrate on Speech Transmission Quality. Participants include Alcatel, Ericsson, Siemens,Nortel, CSELT, and CNET); a complete list of participants is not yet available.

ETSI/STQ TD-09 (S. Moeller, Institut fuer Kommunikationsakustik Ruhr - Universitaet Bochum) is a requestfor membership to TC/STQ received by the ETSI Secretariat. S. Moeller and Mrs. Jekosch (Institut fuerKommunikationakustik Bochum University), who contribute to ITU SG 12 work, are not able to participate inETSI’s work because their University is not member of ETSI. It was suggested that they become member ofTC/STQ through the membership of a German operator such as Deutsche Telekom.

ETSI/STQ TD-06 (R. Maerz, Siemens) contains the minutes of the TC/STQ starter group meeting; thoseminutes were approved on the condition that they be amended as suggested in ETSI/STQ TD-02 (K. Adler,Alcatel). The text of the last bullet of page 2 of ETSI/STQ TD-06 (R. Maerz, Siemens) now reads: “ETSITechnical Report (ETR) 250 is under preparation by Corporate Network (CN) 7”. The title of this ETR is now“Overall Transmission Plan Aspects for Telephony in a Private Network.” ETR 250 gives rules and algorithms, tobe used by transmission planners, rules based on subjective tests.

ETSI/STQ TD-05 contains the terms of references of ETSI TC/STQ as approved by the Starter Group and by theETSI Board.

Since this was the first meeting of TC STQ, there were no permanent documents. J. Pomy (Bosch Telecom) askedthat ETSI/STQ TD-03 (J. Pomy, Bosch Telecom), Overall Speech Quality Aspects in Future Network Scenarios,become a permanent document. This request was accepted.

G. Rose (ETSI Secretariat) introduced ETSI/STQ TD-07 (G. Rose, ETSI Secretariat), proposing TC/STQworking methods. The meeting agreed to operate electronically. The meeting also agreed that TemporaryDocuments (TDs) will be documents tabled as of the Thursday preceding the meeting, and that any document tabledafter that date will be a Working Document (WD). Discussion arose over access to the ETSI Server and to the STQServer. G. Rose (ETSI Secretariat) indicated that ETSI policy is being reviewed. He also indicated that there may besome problems with server documents that are finalized and that can be bought from ETSI Publication Office.

ETSI/STQ TD-04 (ETSI Secretariat) contains the list of temporary documents received prior to the meeting andplaced in the TC/STQ server area stq_a.

ASSESSING AUDIO QUALITY

ETSI/STQ TD-10 (Klause, Deutsche Telekom) is a commentary on audio quality, presented on behalf ofDeutsche Telekom by K. Adler (Alcatel). Transmission of Audio relates to “transparent” transmission whereasTransmission of Speech may include some degradation of the perceived speech quality without significant loss tothe intelligibility of the received signals. These terms differentiate between for example, ISDN audio service andhuman speech, or conversation. ETSI/STQ TD-10 proposes that TC/STQ focus on Speech, as Audio isconsidered to be outside the scope of TC/STQ.

ETSI/STQ TD-09 (A. Bürgi-Schmelz, Ascom) is a proposal for working party specification and measurement ofSpeech Transmission Quality. With the advent of new operators, each claiming lower tariffs, probably at the cost ofreduced speech quality, harmonized speech quality specifications and test methods are urgently needed so that userscan objectively compare the speech quality and prices from different operators. ETSI TC/STQ feels it is prematureto create a Working Party, but endorses the creation of a new Work Item. A. Burgi-Schmelz (Ascom) will be theRapporteur for this new work item.

ARCHITECTURAL ASPECTS OF MODERN NETWORKS

ETSI/STQ TD-10 (Klause, Deutsche Telekom) also comments on the term “Architecture.” It notes thatTC/STQ is not involved in Network Architecture per se; NA is the ETSI group involved with Network Architectureand has a sub group dealing with performances, including not only speech but also traffic delays. In ChairmanPerrichon’s opinion, there are on one side people developing speech coders and processors and on the other sidepeople developing network architecture. In between, there is the need for considerations of interconnection and



transcoding, which is the role of TC/STQ. It was suggested therefore, that the term “Architecture” be replaced by theterm “Inter-operability” in the Agenda Item 6 title.

ETSI/STQ WD-01 (J. Horrocks, DTI - UK Department of Trade and Industry) discusses European TransmissionPrinciples. There is growing anxiety at the Regulator level and at the European Commission level on the speechtransmission quality in a liberalized network operator environment. ETSI/STQ TD-12 (J. Horrocks, UK DTI) isFigure 1 of ETR 275, presenting the different elements of transmission planning and their inter-relationships:• Information on delay sources• Information on other impairments (e.g. distortion)• Likely connection topologies• User perception of end-to-end performance• User view of price, convenience, performance• Approaches to transmission planning• Ability for on-line exchange of performance information between networks

While ETR 275 only evaluates the transmission delay parameter, J. Horrocks (UK DTI) proposes to start similarwork leading to a simple document which would give guidance on the interconnection of networks and speechquality. This proposal was accepted by TC/STQ; J. Horrocks drafted a proposed Work Item (see below). He alsooutlined four areas where TC/STQ may fit within ETSI’s overall responsibilities:• Codecs at the edge of the network• Traditional network planning where delay is the most important parameter, in particular for echo cancellation• Reseller of voice channels over leased lines• Interfaces between traditional network and new technologies; guidance on how to manage those interfaces

TC/STQ also sees some merit in building up a matrix with inputs such as network type, interconnection andoutputs such as end to end Quality of Service (QOS).

ETSI/STQ TD-03 (J. Pomy, Bosch Telecom) is a report from a workshop on inter-working betweenPSTN/ISDN voice and Voice over IP services, which has now become ETSI Project TIPHON. J. Pomy (BoschTelecom) indicated that while TIPHON (Telecommunications and Internet Protocol Harmonization Over Networks)schedules are very tight, TC/STQ should get involved in the speech quality aspects of such services; it is a goodinter-operability example as discussed above. TC/STQ agreed to draft and approved a liaison statement.ETSI/STQ TD-11 (J. Pomy, Bosch Telecom) is a liaison statement prepared and approved by the ITU-T SG 12to SG 16 on the topic of Internet Telephony. This document questions the validity of the choice of the G.723 codecin view of its extremely high transmission delay.

ETSI/STQ WD-03 (D. Gurle, ETSI TIPHON Technical Officer) was received early enough for STQ to reply to itin ETSI/STQ WD-02. This liaison statement was not presented at the TIPHON meeting.

INVENTORY OF AVAILABLE SOURCES

TC/STQ reviewed the ETSI work items assigned to it, and evaluated the need for new work items in addition tothose inherited from previous committees. TC/STQ also identified the Committees with which it intends to makeliaisons:• ETSI/STQ WD-02 (ETSI/STQ) is a liaison statement to TIPHON on Internet Telephony• ETSI/STQ WD-04 (J. Monfort, CNET France Telecom) is a liaison statement to ATA (Analog Terminal and

Access) on speech transmission quality and speech processing techniques• ETSI/STQ WD-05 (J. Monfort, CNET France Telecom) is a liaison statement to Digital Terminal Access

Project (DTA)• ETSI/STQ WD-06 (J. Monfort, CNET France Telecom) is a liaison to Multimedia and Terminal

Applications (MTA) ETSI Projects.These liaison statements indicate briefly the tasks of TC/STQ and its willingness to cooperate actively with thoseETSI Projects on speech transmission quality and speech transmission techniques.

PROPOSED TC/STQ WORK ITEMS

ETSI/STQ WD-07 contains four work items agreed by TC/STQ:

1) Specification and Measurement of Speech Transmission Quality (as proposed by Ascom)2) Speech transmission characteristics for handset terminals using signal processing techniques (from former TE 4

Sub Technical Committee)



3) Objectives and principles for the transmission performance of networks that provide telephony services basedprimarily on their own transmission infrastructure, as proposed in ETSI/STQ TD-13 (J. Horrocks, UK DTI).

4) To identify the transmission delay across public and private switched networks from UNI (User NetworkInterface) to UNI. This identification will enable guidelines to be established for planning complex digitaltransport systems in the access and core networks, in a multi-operator environment, including the provision ofadditional echo devices.

OTHER BUSINESS

A one day workshop will be prepared in memory of Niels Olov Johannesson, the author of the E-model (European,or ETSI Model). E-Model is a transmission quality model which takes into account transmission parameters that arespecific to Europe such as A-law coding instead of µ-law, hybrid balance, and line characteristics. The workshopwill be held in conjunction with the SG 12 Q20 meeting in Bochum, Germany, October 7, 1997. The workshopwill be in two parts:

1) To consider the existing E-model; to get feedback from companies using it; to present assumptions when usingthe existing model; to deliver theoretical papers on that existing E-model

2) To progress/to evolve the model on such items as multiple echo treatment, non linearities and hands freeapplications

Participants in the workshop need not be members of ETSI; international experts are welcome to participate. Theworkshop will provide TC/STQ with a better view of opening new work items related to future of ETR 250 (Speechcommunication quality from mouth to ear for 3 1 kHz handset telephony across networks) and the E-model.

Jacques A. Besseyre, Telecom Consultant

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 ofeither of CSR’s technical journals, please contact Elaine Baskin, tel +1 650 856-9018,fax +1 650 856-6591, e-mail: [email protected]



REPORT OF STUDY GROUP 8 Q1/8 AND Q4/8 RAPPORTEUR MEETINGS,JUNE 23 – 27, 1997, COSTA MESA, CA

QUESTION 1/8, FACSIMILE TERMINALS

Question 1/8 addresses standards issues related to facsimile terminals. The Rapporteur is B. Revillet of France.

EDITORIAL REVISIONS TO T.30 RECOMMENDATION

The editor of the T.30 recommendation, A. Pugh (Matsushita/Panasonic), presented CM2-007 . This version ofTable 2/T.30 documents the updated bit settings for DIS, DTC and DCS signals, as Decided at the February 1997SG 8 meeting. CM2-022 (H. Hertlein, Deutsche Telekom) is a list of corrections from Germany for the 1996version of T.30. CM2-033 (Japanese manufacturers) shows editorial errors which need to be corrected for the 1997version of Table 2 and for the 1996 version of the table. It was confirmed that the 1996 corrections cannot beapplied, since 1996 T.30 has already been published. Therefore, no further action will be taken on the 1996 version.The 1997 version of T.30 is scheduled to have its vote complete by July 2. A. Pugh noted that the purely editorialcorrections for the 1997 version can still be applied during the pre-publication process, once agreed. It was agreedthat an ad-hoc group would review the detailed editorial items and then report back to the main meeting.

CM2-055 is the revision of Table 2/T.30 as revised by the ad-hoc group. It has minor editorial points which areproposed to be submitted to the ITU TSB for inclusion in the already Decided 1997 amendment to T.30. The editsare primarily to ensure consistent references between the table and the related notes. The meeting accepted therecommendations of the ad-hoc group.

NEW FRAMES FOR T.30

CM2-024 (Japanese manufacturers) is a proposal for a required amendment clarifying the EOS (End of Selection)procedure. It notes that the use of EOS for multiple selective polling was not fully defined. It is believed that themethods that have been proposed to date have problems. Therefore, two other methods are proposed. Method Aincludes a slight change to set the multiple selective polling bit to “0” in DTC, prior to polling for the lastdocument. Method B is a more substantial change. After some discussion, it was agreed that more text must beadded to T.30, showing an application example. Further contributions are invited for the next meeting.

CM2-027 (Japanese manufacturers) is a proposed amendment to T.30 to prohibit multiple concatenated use offrames such as SUB, PWD, etc. There is concern that multiple occurrences of these signals are not currentlyprohibited and that this could cause problems. Therefore, it is proposed that T.30 be amended to prohibit this, butthere is no formal proposed text amendments. There was no opposition to the idea. The T.30 editing ad-hoc groupalso planned to work on this item.

The ad-hoc group produced CM2-057 , proposed text for inclusion in Section 5.3.6.1 of T.30. A sentence isproposed for inclusion under the text for the SEP, SUB, PWD, PSA and SID signals, prohibiting multipleoccurrences of the same signal within a single signal sequence. The proposed text was accepted.

CM2-023 (H. Hertlein, Deutsche Telekom) is a proposed amendment to T.30 to add a facility for denoting thatsending or receiving terminals are on a cellular connection. The proposal notes that such a facility is provided inV.8, but is not available for devices that do not use V.8. There was a request that more background is needed onwhy such a bit is necessary. Further review of this document was deferred to the Facsimile Quality of Service ad-hocgroup. Further comments are invited; the document will be re-submitted as a white contribution.

EXTENDED NEGOTIATIONS PROCEDURES (T.30 ANNEX X)

It was agreed at the February SG 8 meeting to Determine a new draft Annex X to Recommendation T.30 onExtended Negotiations and also to add related changes to the main body of T.30.

CM2-016 (A. Pugh, Editor T.30) contains amendments to the main body of T.30, including ENP (ExtendedNegotiations Protocol) related changes. The ENP related changes were reviewed.

CM2-035 (J. Rafferty, USA) is a copy of the white contribution which has already been submitted to the ITU-Tfor draft Annex X. The minor editorial revisions added to the document by the editor after the February meeting werereviewed.



CM2-036 (Delta Information Systems and Rockwell) presents refinements to draft Annex X to T.30. Therefinements are primarily to add some explanatory material to accompany the flow charts and also to providecorrections to two of the flowchart figures.

CM2-031 (Japanese manufacturers) proposes modifications to draft Annex X and the related revisions to T.30 toclarify the application rule for the use of extended negotiations. The request is primarily intended to indicate thatENP would be used for those cases where a specific application required it, such as for Fax Security. In line withthis request, it is proposed that the ENP T.30 bit in the DIS be eliminated and that various changes be made to thetext of draft Annex X.

CM2-032 (Japanese manufacturers) is a series of comments which resulted from review of the text and flowchartsof the draft Annex X as of the February 1997 SG 8 meeting. Most of the points concerned clarification or correctionof the flow charts for ENP.

There was substantial discussion on the documents. Some delegates felt that the refinements proposed in CM2-036 were too extensive for a document which was declared stable in February. There were also several differentopinions on the matter of the application rule proposal requested within CM2-031 . Rapporteur B. Revilletsuggested that one potential disposition for some of the material would be to include it within an implementersguide.

An ad-hoc group was established to decide which text should be included as modifications to the text included withinAnnex X and what information should go within the implementation guide, or be introduced later within Annex X.

CM2-062 is the meeting report of the ENP ad-hoc group. It summarizes the agreements reached by the group,including text changes and small revisions to the flowcharts. It also includes a list of open items which will needfurther review and contributions.

CM2-063 includes the updates to the text of ENP documents. Clarifications were made to the application rule forENP, along with some associated text revisions and revisions to flow diagrams and session examples. It was agreedthat the ENP bit within the DIS would be eliminated, but that a bit would be reserved for future ENP use. Themeeting report and the revisions were accepted.

QUALITY OF FACSIMILE SERVICE AD -HOC GROUP

Various aspects of work related to the Quality of Facsimile Communication was conducted by an ad-hoc group underthe direction of ad-hoc chair A. Giuseppini of Italy. The results of the ad-hoc meeting are summarized in CM2-050 ; the action plan is contained in CM2-058 .

CM2-002 is a copy of Determined draft 3 of E.nonint, from SG 2, Question 2. The purpose of the document is toprovide a way to non-intrusively monitor facsimile calls. It was agreed to send a liaison to Q2/2 reminding themthat the use of V.34 modulation will become significant and should be included in the document as soon as possible.

CM2-010© is the latest revision of E.450, an existing Recommendation on Facsimile Quality of Service on PSTN- General Aspects, from SG 2. CM2-011 is a draft Recommendation E.456 on Test Transaction for FacsimileTransmission Performance. There are errors in some references. Liaisons will be sent to SG 2 noting neededcorrections in both draft recommendations; they will request that such recommendations be sent to Q1/8 for review.

CM2-051 is the liaison statement to SG 2 Q5. It includes comments on draft Recommendation E.nonint and theRecommendations E.450 and E.456; it suggests that these recommendations should be updated to support the use ofV.34 modulation.

CM2-003 is a liaison from SG 15 regarding various recommendations. It contains a statement noting that perrecommendation G.766 on demod/remod, there may be up to 40 ms added to the 75 ± 20 ms gap. They request thatsuch a statement be added to T.30. A. Pugh (Panasonic) noted that this timing is not consistent with T.30. G.Griffith (Rockwell) suggested that the interpretation should be that the existing timing may be increased by up to 40ms. A liaison will be sent to SG 15 asking why a 40 ms gap is present, while noting that this is not compliantwith T.30. SG 15 also noted that they see no problem with the V.34 manual mode for V.8-compliant terminals.

CM2-006 , G.Fax_test, has been Determined by SG 16, Q18. It contains a testing methodology for evaluating theperformance of Group 3 facsimile processing equipment incorporated in the signal processing network elements(SPNE) of the PSTN. Two types of SPNE, CME and echo cancellers, are addressed in the document. A.Guiseppini (Italy) proposed that an initial liaison be sent now and that a more complete response be sent from theOctober SG 8 meeting.



CM2-001 is information about the Quality of Service Development Group (QSDG). This group is affiliated withthe ITU, but does not have formal status within SG 2. Most of the participants are from developing countries. Itappears that a paper which SG 8 had requested is considered “confidential” and not available for distribution.However, in CM2-013 , the chair of Q5/2 notes that the chair of QSDG will attempt to have a copy of the docu-ment made available to SG 8 from its original source.

CM2-012 is a liaison statement from Q5/2. It provides general background information about how the phonenetwork has evolved in areas such as incorporation of digital technology and DCME equipment. It was decided thatno response is needed.

CM2-049 (Italian PT Ministry) notes that an ad-hoc group has been set up among OMNITEL and TIM (networkproviders), Ericsson and Nokia (mobile manufacturers) and ISPT (Italian PTT) to test the quality of fax commu-nication when interworking between the PSTN and mobile networks. Participation of other organizations is alsoinvited.

CM2-028 (Japanese manufacturers) proposes an amendment to D42 (Germany, SG 8, Feb. 1997) on the point ofthe T4 timer for manual and automatic units. D42 had proposed that the T4 timer be set to 3 sec ±15% for manualmode in addition to the automatic mode. CM2-028 notes that the 4.5 second (±15%) for manual units helps toavoid re-try conflicts; a proposal is included for text changes to T.30 consistent with the approach outlined. H.Hertlein (Deutsche Telekom) responded that in Germany they have seen no cases where the 4.5 sec timing is usedand that the likelihood of a deadlock on a manually originated call is very small. Y. Kudo (Toshiba) noted that somemanufacturers do use the 4.5 sec timer for manual operations. Additional contributions were requested, due to thedifference of opinions.

On the matter of response time between a binary coded signal and the high speed modulation (par. 5.3.2.4, >75 ms),which had been previously reviewed in D44 at the last SG 8 meeting, H. Hertlein confirmed that there is still a needto do further work on this item and that a contribution will be developed for the next meeting.

CM2-052 is a liaison to SG 15 Q6 regarding facsimile demodulation/remodulation by DCME. It asks forclarification on the cause of delays introduced by the use of DCME per G.766.

CM2-053 is a reply liaison to SG 15 Q6 on the Determined G.Fax_test draft recommendation. A question wasraised on a discrepancy between delays referenced in Rec. G.766 and in the appendix of Rec. G.Fax_test. A moredetailed response will be submitted after the next SG 8 meeting.

M IXED RASTER CONTENT COLOR FAX

The full set of documents on the changes to T.4 and T.30 to incorporate Mixed Raster Content were Determined atthe February meeting of SG 8 for proposed approval in October 1997. At that time, it was agreed that further edito-rial work was required on the documents; Question 5/8 met the week of May 13 to prepare the final text for draftRecommendation T.44, Mixed Raster Content (MRC), and the related changes to T.4 and T.30. CM2-046 is themeeting report from that Q5/8 rapporteur meeting. Agreements were reached on the following documents:

1) Revised draft Rec. T.44 (CM2-030 , L. McIntyre, Xerox)2) Revisions of amendments to T.4 for MRC (CM2-015 and CM2-017)3) Revision of Rec. T.30 (CM2-016) and new Annex Y (CM2-029) to T.30.

Y. Yoshiura (Canon) introduced the documents which contain draft Recommendation T.44 (CM2-030) and therevisions to T.4 and T.30. CM2-015 is the new annex to T.4. CM2-046 describes the plan to support newMRC capabilities by creating new annexes to MRC. Since these documents had been reviewed in detail at theQuestion 5/8 rapporteurs meeting and have already been submitted as white contributions, the group agreed that nofurther technical review was needed at this meeting.

BINARY FILE TRANSFER NEGOTIATIONS

It was agreed at the October 1996 Q1/8 meeting to work on two methods for BFT negotiations: an approach basedon extended negotiations with a means to conduct BFT negotiations within Phase B, and a second approach whichsubmits BFT tags within the Phase C portion of the fax procedure. The Phase C BFT negotiations method proposedto date does not provide a way for a receiver to do BFT capabilities in advance of a BFT file transfer request.

J. Rafferty (Human Communications) presented CM2-037 and CM2-038 on BFT negotiations within Group 3fax (both from Delta Information Systems and Rockwell). CM2-037 presents technical requirements for



supporting BFT negotiations in both Phase B and Phase C. It contains a proposal to progress the work by creatinga new annex to T.30 and by making revisions to the main body and other annexes of T.30. CM2-038 is an initialdraft of the new proposed draft Annex Z and other proposed modifications to T.30 and other annexes and appendices.B. Revillet (Rapporteur) asked if it was feasible to expand the scope of the existing T.30 Annex B to include theAnnex Z material; it was agreed that this seems feasible. The documents were accepted by the group as the basis forfurther work. Work will continue by correspondence.

V.34

CM2-003 is a liaison from SG 15; SG 15 has identified no problems with the manual mode of V.34.

CM2-014 contains the proposed amendment to Rec. T.30/Annex F, which is an additional V.34 polling example.The revision was accepted. It is slated for Decision at the October meeting of SG 8.

CM2-034 (Japanese manufacturers) proposes a new procedure for manual communication in V.34. This issue,previously discussed in D17 (SG 8 February 1997), concerns the use of CNG to indicate that a fax terminal is intransmit mode, and the conflict that arises when V.8 and V.34 definitions of call and answer are used. A. Pugh(Panasonic) stated that CNG is not adequate for the proposed task and will create bigger problems. The principle of amanual communication mode was agreed. It was agreed that there is a need to clarify the use of CNG to indicate thata fax terminal is in the transmit mode. It was agreed to write a liaison to SG 16 requesting the modification of V.8and V.34. There was also a proposal to send liaisons to SG 15 and SG 11 regarding echo cancellers. An ad-hocgroup was formed to write the liaisons. CM2-065 is the liaison to SG 16 requesting modifications to V.8 andV.34 in support of manual operation; CM2-064 is the liaison to SG 15 and SG 11 respectively concerning theproper operation of echo suppressors and false detection by SS5 if the facsimile terminal sends the appropriatesignals from the calling side.

GROUP 4 FAX AMENDMENTS

CM2-040 (T. Yamamoto, Japan) is draft Amendment 2 to Rec. T.563, Terminal Characteristics for Group 4Facsimile Apparatus. This is a copy of a white contribution that has been submitted to SG 8. It adds to G4 the ex-isting signals SUB, SEP, PWD and the new signals SID, PSA and FNV. B. Revillet (Rapporteur) suggested that itis better to copy the relevant sections of T.30. J. Rafferty noted that the exact definitions are actually containedwithin section 5.3.6 of T.30 and suggested that a sentence making these references be added to the text of sectionX.3. Text will be prepared for review on this matter.

LIAISONS

CM2-025 (Japanese manufacturers) proposes a liaison to ISO/IEC SC 28. There are three proposed standards(ISO/IEC DIS 15404-1, -2, -3) for characteristics of facsimile equipment which have some technical inconsistencieswith ITU fax Recommendations. CM2-045 (L. McIntyre, Xerox) supports the same position as CM2-025 . H.Hertlein (Deutsche Telekom) suggested that sending a liaison will accomplish nothing, since the September meetingof this group does not have these fax issues on the agenda. Later in the meeting, CM2-056© was introduced. It is acopy of ISO/IEC DIS 15404-1, Facsimile Equipment Part 1: Concept and classification; DIS 15404-2, FacsimileEquipment Part 2, Minimum requirements for documents to be transmitted; and DIS 15404-3, Facsimile EquipmentPart 3, Minimum requirements for received copies. There was discussion on preparing a general liaison to ISOnoting that some countries will be forwarding comments directly to ISO. This idea was supported.

CM2-067 is a liaison to ISO expressing the concerns raised with the proposed standards for fax equipment. It wasaccepted with minor modifications.

CM2-005 is a liaison statement from SG 16 on the status of ASVD (Analog Simultaneous Voice Data)deployment. It notes that at this time, the work on V.34Q is on hold, due to lack of agreement on alternativetechnology directions.

CM2-004 is a liaison from SG 16 on codepoints for V.8 and V.8bis. It includes a draft of the Implementer’sGuide which was approved at the March 1997 SG 16 meeting. A procedure for requesting new codepoints via arequest to the SG 16 chair has also been agreed. SG 16 is also considering the establishment of a web page whichwould include the latest information about codepoints.

CM2-041 is the editor’s draft of the V.8/V.8bis Implementer’s Guide which has not yet undergone full review bythe TSB, and has no official status. B. Revillet suggested that perhaps that this procedure would eliminate the needto proceed with T.codes. H. Silbiger (Lucent) felt that T.codes should proceed. J. Rafferty (HumanCommunications) suggested that the final decision on the disposition of T.codes should be made in the Study Group



meeting. A. Pugh (Panasonic) suggested that T.66 (formerly T.codes) should perhaps be retained as a place todocument application rules on how to apply the facsimile-related codepoints for V.8 and V.8bis. It seems that it isnot clear within SG 16 whether codepoints contained in the Implementer’s Guide will continue to be maintainedwithin the V.8 and V.8bis Recommendations.

A. Pugh (Panasonic) referenced Circular No. 3, which defines the use of an implementer’s guide within ResolutionNo. 1. He noted that different study groups are interpreting the use of implementer’s guides in different ways. Itwas agreed that an ad-hoc group should clarify the needs for T.66 and also prepare a liaison to SG 16 with theconclusions of the Q1/8 Rapporteurs group. CM2-059 is the liaison to SG 16. It notes some discrepanciesbetween the draft V.8/V.8bis Implementer’s Guide and the proposed T.66. Information was also provided about thestatus of T.66 and the need for SG 8 to include application rules related to V.8 and V.8bis codepoints.

QUESTION 4/8, DOCUMENT COMMUNICATION SERVICES

The Q4/8 meeting was convened by Rapporteur H. Silbiger (Lucent, US). This question has taken overresponsibility for various F.series documents on fax and document communications service requirements; thesetopics had been addressed within Study Group 1 during the last study period.

The main topic of discussion was on facsimile over the Internet and related service requirements.

SESSION -BASED REAL -TIME INTERNET FAX

Session-based Internet fax is analogous to fax over the PSTN where part of the transmission path includes a segmentusing the Internet.

CM2-043 (Delta Information Systems, Lucent, and Rockwell) contains a proposal for a definition of real-timefacsimile over the Internet. It concludes that the two requirements are:• The content and sequence of standard T.30 messages is preserved• The call duration for real-time Internet fax is comparable to that of a Group 3 facsimile session using the PSTN

between the same two terminals.During the discussion, it was noted that there may be cases where some of the T.30 signals are not relevant. Thetwo key principles of CM2-043 were agreed, with the first sentence of principle 1 being amended to read: “The con-tents and sequence of standard T.30 messages exchanged between the sending and receiving terminals is preserved,where appropriate.”

CM2-008 (D. MacTaggart, CyberFax, Canada) presents the results of trials for session-based facsimile over thepublic Internet using the method presented in CM2-009 (below). Trials were conducted using actual G3 facsimileterminals, where the transfer medium was the public Internet. CM2-008 concludes that it is possible to obtain aquality of service which is equivalent to the PSTN, if the access connection is “close to” the Internet backbone. Italso notes that special techniques for using T.4 and T.30 at the gateways are needed to achieve this quality, but thetechniques are legitimate per the fax recommendations. It is also noted that about 5 seconds is needed for packetiza-tion and that the actual page transmission is about 5 seconds.

CM2-009 (A. Ronen, RAD, Israel) proposes an Internet facsimile transmission protocol for communicating faxmessages over the Internet between gateways. The proposed protocol may be used over IP networks using eitherTCP or UDP (User Datagram Protocol) connections. It defines a way to packetize T.30 messages and data. B.Revillet (France Telecom) asked about the relationship between X.38/X.39 and this paper. D. MacTaggart statedthat this paper has learned from the experiences with X.38/X.39, but is not closely related to these recommendations.After an extensive discussion, delegates requested further clarification and contributions related to the followingpoints:

1. Handling of fax addressing, including phone number, subaddress and relationship to Internet addresses.2. The issue of using TCP vs. UDP as the underlying Internet protocols.3. Provisions on handling the CFR and the newer T.30 signals (FNV, Fax Security and ENP), possibly through

multiple exchanges of the T30_ CALL_CONF frame.4. Handling of other types of fax data in addition to T.4 image.5. Handling of ECM vs. non-ECM, due to the differences between the fax protocol in these two cases.6. Error handling in the case that an RTP or RTN signal is sent from the receiver back to a gateway.7. Quality of services issues for fax over the Internet, including the acceptable quality range.8. Special issues related to handling of V.34 fax, due to protocol differences, potential for data rate mismatches,

entry via V.8, and setting of data rates in V.34.9. Handling of the general case where there are data rate mismatches between the ultimate end terminals.



10. Information to be contained in the Call_Req frame, notably the vector keys for Phone Number, Vendor andProduct Information and Caller Information.

STORE AND FORWARD BASED INTERNET FAX

Store and forward based Internet fax is a generic term which includes messaging or e-mail-based fax.

CM2-039 (Japanese manufacturers) proposes that a “primitive” mode of Internet Fax via e-mail be standardized,where there is no negotiation of capabilities and no confirmation of receipt. The contribution reviews the objectivesfor Internet fax that were agreed at the February SG 8 meeting and concludes that the requirements for identificationof capabilities and confirmation of receipt are not consistent with the current capabilities of Internet e-mail. Thepaper concludes that it will be better for the initial Internet fax products to use only current Internet e-mailcapabilities. It was noted that there are products in Japan called Internet fax which operate in the manner of theprimitive mode. Concern was expressed that this kind of limited mode does not provide the features which usershave come to expect for facsimile and which provide the principal characteristic of facsimile service. The Rapporteurnoted that more detailed contributions are needed before a decision can be made on whether to develop an ITUrecommendation that meets this reduced fax criteria.

CM2-026 (T. Maeda, Canon) discusses the concept of the Lowest Common Denominator for Internet fax. Itconcludes that the term Internet fax should mean that there is an “Internet fax protocol” and that such a protocolshould include confirmation and identification of terminal capabilities. T. Maeda clarified that the paper is onlyaddressing the case of message-based fax, not real-time.

FILE FORMATS FOR INTERNET FAX

M. Lake (UK) presented CM2-018 , a file format proposal for Internet fax over non-real time transport services.This document is similar one submitted to the February Q4/8 meeting, with small changes. This approach does in-clude facilities for negotiation of capabilities and confirmation of receipt. Capabilities are stated by using the datacontent from T.30 signals, which is embedded within the file format, along with the actual T.4/T.6 image data. Theletter on Intellectual Property Rights related to this work has been sent to the TSB.

CM2-044 (L. McIntyre, Xerox) proposes the use of TIFF-FX, a file format under development in the IETF faxworking group. As is the case in the UK proposal, this would support all image compression methods presentlystandardized in T.4 and T.30. It was pointed out that the UK proposal would not need to be revised if new featureswere added to T.30, which would not be true for TIFF-FX. The Xerox proposal could not be subjected to furtherexamination, since the text of TIFF-FX was not supplied.

CM2-018 (the UK proposal) was discussed in detail. It was noted by the Rapporteur that standardization of a fileformat was only one item in the process of standardizing non-real time facsimile communication. Methods for ac-cessing the service and transmission of the designation address in the case where the destination was a conventionalfax terminal will also need to be specified in a recommendation.

It was not clear what the effect would be of failure to decode one of the pages. While support for the new framesused by Fax Security and ENP would be difficult in this method, other methods for obtaining security in e-mail-based systems have been standardized elsewhere. Support for future new frames would not be difficult, since theT.30 frames are included in the message format.

It was agreed that the UK proposal is the only proposal for a message format which is currently available for reviewand it seems to meet the agreed criteria for Internet fax. It was agreed to continue work on this proposal. M. Lakenoted that various issues have been raised and that there is further work which could be done preparing informationabout the system that would use this format. An ad-hoc group was convened, chaired by M. Lake, to work onoutlining the system requirements for e-mail-based facsimile. The report of the ad-hoc group is in CM2-066 .

The ad-hoc group concluded that three recommendations should be developed: one service recommendation, andseparate technical recommendations for e-mail and real-time fax. Drafts for the service recommendation (F.ifax) andfor the e-mail-based technical recommendation (T.ifax1) were developed and attached to CM2-066 .

In discussion, the following points were made:• Each of the diagrams on page 5 of proposed F.ifax should have an explanatory paragraph.• The responsibilities of gateways should be described in detail.• A note should be added to the table in 5.4 to indicate that ECM may be available in store and forward mode in e-

mail-based systems between the gateway and terminals. The use of ECM in real-time systems is for furtherstudy.



• The description of the capabilities exchange and its use needs to be further elaborated.

The report of the ad-hoc group was accepted. It was also agreed that the two proposed draft recommendations reflectthe current level of agreement in Q4/8 and should be submitted to SG 8. M. Lake agreed to act as editor for the twodocuments.

OTHER FACSIMILE SERVICE REQUIREMENTS

H. Silbiger presented CM2-020 , draft revised Recommendation F.182 - Telefax 3 service; and CM2-019 , draftnew Recommendation F.182bis, Guidelines for Group 3 terminals, which were agreed by SG 1 at its last meeting.

Draft Rec. F.182bis describes guidelines for communication of documents using Group 3 facsimile betweenterminals over public networks. Revised Rec. F.182 includes provisions for a public fax service; F.182bis wasextracted from the original F.182.

It was proposed that Rec. F.182 be deleted, since public facsimile services are no longer being operated. There was arequest to delay such a decision until the October, 1997 meeting.

USE OF EDH

A. Pugh, the chairman of SG 8 WP T, pointed out that not much use was being made of the Electronic DocumentHandling (EDH) facilities provided by the ITU. Specifically more use should be made of the SG reflectors toprogress discussions during the period between meetings. It was agreed that the meeting reports would be distributedon the reflector in addition to their submission as white documents.

COMMUNICATION WITH THE IETF

Since there currently is an Internet fax working group within the IETF, it would be appropriate to communicate tothem informally the current status of the work in Q4/8. This might avoid some duplication of effort.

James Rafferty, Human Communications



REPORT OF Q11/16 AND Q15/16 JUNE 24 – 27, 1997, PORTLAND, OR

Q11/16, CIRCUIT-SWITCHED NETWORK (CSN) MULTIMEDIA SYSTEMS AND TERMINALS

The goals of the Q11/16 meeting were to complete H.324 Annex C and H.223 Annexes A, B, and C (all for mobileoperation) for Determination at the SG 16 Working Party 2 Meeting, September 1997; and to work on H.dispatch,H.324/I, H.multilink, and appropriate annexes to H.246 (interworking).

One joint meeting was held with Q15/16 (Advanced Video Coding) to work on the definition of H.263+ modeselection and support signaling in H.245 (control protocol). This work will be continued by an ad hoc group underQ15/16 and at the September 1997 joint meetings in Sunriver, OR.

Q11/16 strongly believes it will have the proposed draft texts available for determination at the September 1997 SG16 WP2 meeting.

There were no contributions specifically targeting the Annexes to H.246 concerning interworking, although therewas considerable work in this area in general.

Q11A00r1-e (Q11/16 Rapporteur) is the list of contributions presented at the Q11/16 meeting.

SYSTEM, CONTROL , MUX , INTERWORKING

Q11-A-16 (SG 12) is a liaison that contains useful information on lip-synch, and delay, video quality measurement.Q11/16 agreed to point out the delay issues to Q15/16, particularly regarding video coding delays, and to theappropriate questions of WP1/16, regarding modem delays. A liaison to SG 11, Q11-A-63-e , requesting a Q.931codepoint for H.324/I (as proposed in Q11-A-33-e , Y. Tomita, NTT), was approved.

Q11-A-68-e and Q15-A-58-e (Q11/16 and Q15/16) were approved as liaisons to SG 12 thanking them for theirresponse regarding performance aspects of audio and video in multimedia terminals.

Seamless V.34 Rate Change

Q11-A-21 (Q11/16 Rapporteur) documents the new V.34 seamless rate change command in V.25bis, which isuseful for switching V.34 modem rates without data dropouts. Control of modem rate is by V.80 only, and cannotbe done by DTE control in direct sync. Reporting of modem rate changes is also in V.80, and can also bedetermined in direct sync mode by monitoring Transmit/TX/RX clocks.

H.dispatch

Q11-A-19-e (S. Bhagat, PictureTel) is the latest draft of H.dispatch (planned as V.108). It was accepted, withsome comments for minor editorial changes.

Q11-A-29-e (S. Bhagat, PictureTel) contains proposed H.245 EndSessionCommand codepoints to supportH.dispatch. It was accepted, with the comment that new ISDN modes should go in V.108, not inEndSessionCommand.

Q11-A-32-e (K. Hibi, Sharp Corporation) includes comments on H.dispatch and how it is utilized in H.324/Iterminals. Concerns are noted on the relationship of H.dispatch, H.multilink and H.324/I.

H.320, Narrowband Visual Telephone Systems and Terminal Equipment

The H.320 documents were reviewed jointly with the Q15/16 video coding group, as were all the documents relatedto video.

Q11-A-31-e (C. Cheung, VTEL) proposes to include H.263+ features in H.320. Q11-A-59-e (S. Okubo, GCL)comments generally in support of the proposal in Q11-A-31-e . After discussion, the general idea of H.263+support in H.320 was agreed. The details of appropriate H.242 signaling were agreed to depend on the outcome ofthe H.263+ “profile” work. Q11-A-59-e (S. Okubo, GCTech) cautions that a subset of the general H.263+profiles should be used, and account should be taken of H.246 gateway mapping from H.242 to H.245 control; theywere agreed to be important. An ad-hoc group was formed to study the signaling issues further for the September1997 meeting.

Q11-A-57 (T. Johanson, Tandberg) is a proposal for an extension of Continuous Presence Multipoint (CPM) inH.320. Concern was expressed that this proposal was not made in previous meetings because it may cause otherproblems. The H.320 video ad-hoc group was asked to consider this issue.



H.324, Terminal for Low Bit Rate Multimedia Communication

Q11-A-47-e (D. Lindbergh, PictureTel) is the current set of changes to H.324 version 1 needed to produce H.324version 2, as they were Determined by SG 16 in March 1997. The contribution was accepted with no changes.

Q11-A-33-e (Y. Tomita, NTT) proposes adding a codepoint for H.324/I to Q.931. Q11/16 agreed to send a liaisonto SG 11 asking for the addition, with the caveat that Q11/16 wants the codepoint only if it would not cause theISDN network to refuse to complete a call based on incompatible bearer capabilities. One use for the codepointwould be to allow a terminal to reject incoming calls based on inability to run H.324/I. Q11/16 will change the de-scription of the codepoint to “Rec. H.324 Annex D” and ask for inclusion of a note stating that this codepoint doesnot imply bypass of the H.324 Annex D V.108 procedure. Additionally, text will be added to H.324 Annex Dreferencing the codepoint.

Q11-A-63 (Q11/16) is a liaison to Q11/11 discussing new code point in Q.931 for H.324 Annex D (H.324/I)terminals. The contribution was approved.

Q11-A-43-e (C. Quist, KPN) proposes use of ITU-T I-series supplementary services for H.324/I. It is notcompletely clear how this use would be accomplished. Q11/16 may need new procedures, and perhaps newcodepoints; for example, to perform a call transfer, send EndSessionCommand might be sent with a new “transfer”codepoint, then the data call transferred using ISDN, then a new session started at the new destination.Contributions were solicited for details to go into H.324 Annex D (H.324/I). The general idea was supported butQ11/16 wanted to see more details before deciding which parts to accept.

Q11-A-55-e (T. Nakai, OKI) is revised text for H.324 rev. 2 to support H.263 Annex N (reference pictureselection mode). The third sentence of H.324 section. 6.6.1.1 (reference picture selection mode support) second para-graph should be changed to read: “The LCs [Logic Channels] for the video backward channel messages shall next beopened by the terminal which originated the video LC. The backchannel LCs shall be opened as bi-directional LCswith the LC dependency parameters indicating dependency on the corresponding video LC flowing in the samedirection.” The last sentence of the second paragraph should read: “In the case of uni-directional videocommunication, a single bi-directional LC shall be opened, which shall support H223 AL3.” The H.324 editor willmake these changes to the H.324 version 2 change document, and post the result to the reflector for comment.

Q11-A-32-e (K. Hibi, Sharp Corporation) describes comments on draft H.324 Annex D (H.324/I) relating toH.324/I terminals, H.324/I (Annex D), H.dispatch and H.multilink.

H.mult i l ink

Q11-A-45-e (B. O’Mahony, Intel) proposes a modification to the draft H.multilink to use standard 8-bit HighLevel Data Link Control (HDLC) flags. This modification has the advantage of compatibility with the framed sub-mode of V.80, rather than the transparent sub-mode, which some modem/V.80 vendors have not implemented(although it is mandatory in V.80). This change adds some complication, and limits H.multilink to transportingHDLC framed protocols.

An alternative modification was suggested, in which 16-bit word stuffing (similar to the byte stuffing mode ofISO/IEC 3309) would replace the 16 bit bit-stuffing of the current draft. This preserves the generality ofH.multilink, while avoiding the need for complex bit-stuffing.

Decision on this modification was postponed, pending further evaluation of the alternatives. Contributions weresolicited, with a goal of deciding what to do at the September 1997 meeting.

H.245, Control Protocol for Mult imedia Communicat ions

Q11-A-56-e (Y. Tomita, NTT) proposes H.245 V3 syntax revisions to improve the indication of support ofH.263 Annex N, with a description of procedures for setting up video backchannels per Annex N. The H.245 V3editor (M. Reid, PictureTel) will work with Y. Tomita (NTT) to revise and clarify the proposed semantics.

Q11-A-64-e (P. Long, Smith Micro) describes possible difficulties with how ASN.1 extension additions in H.245are handled from one version to another. A terminal shall obey all commands, yet it may ignore an extension.Since there is no response to a command, the sending terminal will not know whether the receiving terminalcomplied. Q11/16 decided that some clarifying text should be added to explain that new modes require capabilities.The issues raised in the contribution should be discussed further on the Q11 reflector.

H.245 COMMAND AND CONTROL

The work on H.245 was primarily with regard to version 3, in support of H.324 system and H.263+.



Q11-A-16 (SG 12) is a liaison from SG 12 concerning characterization and delay issues. The contribution wasprovided for information. Q11/16 agreed this information could also be of value to SG 16/WP1.

Q11-A-48-e (P. Long, Smith Micro) proposes that the H.245 UserInputIndication indicate support for all 16DTMF symbols. It was agreed that some text clarification may be needed; the editor agreed to draft text for the nextmeeting.

Q.11-A-49-e (P. Long, Smith Micro) proposes that the unconstrained ASN.1 components added since H.245Version 2 was Decided be constrained before Version 3 is Decided to allow simpler implementations and avoid possi-ble interworking issues. As the text in question relates to H.323 syntax, the editor agreed to follow-up on this withthe H.323 sub-editor.

In addition the group agreed to draft text along the lines outlined in Q11-A-50-e (P. Long, Smith Micro) forinclusion in an informational appendix to direct future H.245 syntax development towards explicitly constrainedsyntax.

The group tentatively accepted, after review of current H.324 usage, to remove the ambiguity of “present-but-empty”case of OPTIONAL syntax currently in Version 3, and add an informational note to that effect in the next revision ofthe text.

An additional interoperability problem in the H.245 MultiplexEntrySend Specification and Description Language(SDL) was presented in Q11-A-52-e (P. Long, Smith Micro). There is a flaw in the H.245MTSE SDL thatprecludes sending the MultiplexEntrySend message with multiple entries if there are any entries in common betweenit and any of the preceding MultiplexEntrySend messages. The group decided that a modification was necessary inthe applicable SDL and that this should be posted to the implementer reflectors as soon as possible and presented atthe next meeting as well.

Q11-A-53-e (P. Long, Smith Micro) presents informative text regarding the PER encoding of H.245 extension.H.245 V1 is the base version for H.324, and H.245 V2 is the base version for H.323; however, H.245 is extensibleand endpoints must be interoperable with subsequent versions of H.245. In order to encourage compatibility withfuture editions of H.245, this document briefly describes the requirements for decoding Aligned PER ASN.1extensions additions. This text was found to be a valuable item to H.245 implementers, and thus it was agreed itwould be added to an existing informational Appendix in H.245.

Q11-A-40-e (P. Long, Smith Micro) notes there is some confusion among implementers regarding the use of thetemporalspatial tradeoff codepoint. After some discussion, it was determined that the Recommendation is correct; anaddition to the existing Appendix in H.245 clarifying the usage in bi-directional channels will be drafted by theeditor. This is to be an inclusion in H.245 Version 3.

Q11-A-29-e (S. Bhagat, PictureTel) proposes modifications to the existing codepoint EndSessionCommand inH.245 to provide means for a terminal to signal its intention to run a selected protocol (not limited to H.dispatch),as a means to continue communications in another mode. Q11/16 agreed to add the syntax to H.245 Version 3.

The Advanced Video Group (Q15/16) proposed additional codepoints to H.245 in support of a video back channel. Itwas noted that the same work is being addressed in Q13/16 and that coordination with their work is desirable. It wasagreed to tentatively include the requested codepoints pending future contributions from ad hoc and formal effortswith Q13/16.

Future H.245 Work

There will be considerable work to assure the necessary command and control signaling in support of the Mobilework. It is expected that much of this work will be accomplished on the reflector in advance of the SeptemberExperts meeting.

MOBILE

B. Wimmer (Siemens) was appointed the chairperson for this activity, and will also be the editor of H.223 AnnexesA, B and C (Level 1, 2 and 3). The Mobile group report is Q11-A-65-e .

This was a successful meeting. The group worked through many very difficult issues and achieved the necessaryprogress to meet the goal of having the proposed text for H.324 Annex C and H.223 Annexes A, B & C availablefor Determination in the September 1997 SG 16 WP2 meeting. H.324/Annex C will describe the overview of themobile extensions for H.223. H.223/Annex A to Annex C will document:



•Detailed structures and procedures of the levels, which will describe the exact details of each level structure(multiplex layer and adaptation layer)

• Procedures for setting up a level at the beginning of a call• Procedure of changing the levels during a sessionIf approved these documents will be basis for the White Documents for Decision at the January 1998 SG 16meeting.

The mobile group has converged on a multilevel multiplex structure. This multiplexer has four levels, representingprogressively more robust, and more complex approaches. Each level will be specified in a separate H.223 Annex,from Annex A to Annex C. This structure is illustrated in Figure 1.

plain H.223

longer synchronization flagno HDLC 0-insertion

Level 1 + improved header withmultiplex payload length field

Level 2 + improved error pro-tection of the adapation layer

Level 3

Level 2

Level 1

Level 0

Figure 1. Mobile H.223 level structure

An H.324 terminal shall support level 0 and may support level 1, levels 1 and 2, or levels 1-3. All levels are basedon variable length Protocol Data Unit Multiplexers (MUX-PDUs).

H.223 - Leve l 0This level supports the H.223 bit stream, which is generated by H.223. All mobile terminals shall support thislevel. This guarantees interoperability between existing H.324 terminals and mobile ones.

H . 2 2 3 - l e v e l 1This level replaces the HDLC synchronization flag by a PN sequence, which might be 16, 24 or 32 bit. One lengthwill be chosen for the standard. In addition, this level will no longer use HDLC 0/insertion. This method preservesbyte alignment, avoids 0-stuffing errors in the payload field and significantly improves synchronization. Thedescription of level 1 is in H.223/Annex A.

H.223 - Leve l 2Simulations presented at this meeting demonstrated that the use of a multiplex payload length field (MPL), asincluded in levels 2 and 3, allows the synchronization to be nearly as reliable as when fixed-length MUX-PDUs areused. In H.223-level 2, the identical synchronization flag of level 1 will be used. The new header might beprotected against errors by an Extended Systematic BCH code, a Golay code, a CRC (Cyclic Redundancy Code) algo-rithm or by a concatenated BCH-code. The next meeting will decide on one of these four options. This headerstructure is also used in level 3.

H.223 - Leve l 3The multiplex layer, synchronization flag and header, remains the same as in level 2. This level defines an errorprotection for adaptation layer. The procedures and basic fields are very close to H.223, however the protection toolswere taken from former H.223/Annex A (see old draft version on Pictel ftp-site). The error protection codecs are stillunder investigation. The final decision on Rate Compatible Punctured Convolutional (RCPC) codecs or Reed-Solomon (RS) codecs will be made at the next Q11/16 meeting in September 1997. However, level 3 also gives acode point for using proprietary codecs. A manufacturer can thus also supply his terminals with his own codecs,which may be superior in a particular environment. (Example: in GSM, codec A is superior; however in PersonalHandyphone System, codec B may be better).

Simulation Parameters

For the final decisions on unspecified parameters Q11/16 decided to make further simulations; Q11-A-65-e definesin detail how the experiments are to be performed.

The experiments address the problem of providing multiplexing and de-multiplexing in an error prone environment.Currently, the mobile multiplexer is designed to provide to the user a varying degree of error resilience. This



varying approach begins with the lowest level, Level 0, which is simply H.223. Level 1 replaces the HDLC flagsof H.223 with a PN sequence (to be defined). The resilience of the multiplexer is further enhanced in Level 2 bytwo-different options. Option 1 utilizes both the PN sequence and a length field, MPL, and has the capability toeither detect and/or correct errors, which corrupt the header. The method used in option 2 utilizes a set of BCHcodes, which are concatenated in order to protect the mux header. Finally, in level 3, the adaptation layer is modifiedto provide protection to the payload. In the experiments, these approaches will be analyzed in order to determine theprecise parameters to be standardized.

Capabi l i t i es Exchange

The mobile group also agreed to set up the code points for:• Exchanging the capabilities of the different levels• The code points for the procedure of changing from one level to another

The procedure of starting with one level at the setup phase of the H.324 call could be V8bis exchanges or inbandsignaling.

Changing lEve ls During a Sess ion

Changing between levels during the session uses the following procedure:1) Terminal A sends an H.245 message, indicating that a level change has to be made to the corresponding partner

terminal B. This message also includes the level, which shall be chosen next, and the new capabilities ofterminal A for each open logical channel after the change has taken place.

2) Terminal B shall immediately response to the H.245 message initiated by terminal A. The response can eithercontain an Acknowledgment (ACK) or Non-Acknowledgment (NACK). In the case of an ACK this messageshall also contain the new capabilities of terminal B for each open logical channel after the change has takenplace.

3) After terminal A receives the ACK message it shall stop transmitting MUX-PDUs with payload; it shall transmitonly synchronization flags of the new level in its complementary order. (If the new level is 2 or higher, a headerfield shall follow each complementary flag, which indicates “stuffing method.” The minimum number of syncre-transmissions shall be at least 1, but as a maximum 63.) It shall erase all buffers, timers and retransmissionrequests and clear all counters; it shall transmit valid MUX-PDUs of the new level (no inverse sync flags).

4) Terminal B shall immediately response to a received inverse sync flag of the new level as described for terminal Ain paragraph 3, above.

5) If this procedure fails, both terminals switch back to the previous level. After this it might happen that a bit-wisesearch for the sync flag becomes necessary.

Conclus ions for Mobi le Work

The mobile group worked out the main technical features of the mobile multiplexer, which consists of four levels.It was agreed that some options require further study and shall be decided on the next meeting in September 1997.The mobile group also decided that higher levels might be included in future. However the consensus of the groupwas that a new level should result in a significant performance improvement.

TEXT TELEPHONY

Q11/16 made very good progress. G. Hellström (Omnitor) was appointed the Chairperson to head this new ad hocgroup in Q11/16. Q11-A-18-e is the meeting report from Q3/16 discussions on text conversation. Q11-A-61-eis the report of this ad hoc.

V.chat Development Plan

Q11/16 agreed on the following general plan for ITU-T development of text conversation:

V.chat: Q9/16 should develop a simple “V.chat” recommendation, based on ISO Unicode + some control characterssuch as NEWLINE, BELL, BS, TAB, ITALIC, BOLD, etc. ISO 6429 is a possible reference for control characters.There may be need for a simple capabilities exchange (in-band to V.chat) for Unicode subsets. V.chat should be asimple “dumb terminal” protocol that directly sends a Unicode character for each keystroke, without buffering,framing, or error correction. V.chat should be capable of running directly on a 300 bit/s FSK modem such as V.18or V.21, as well as on other transports. An outline of such a protocol is specified in Q11-A-12b-e (G. Hellström,Omnitor).



H.245 support: V.chat should be able to run directly in a H.245 Logical Channel (in place of the V.18 modem). Tosupport this, a H.245 codepoint should be allocated for V.chat as a “Data Application.”

H.323 support: H.323/H.225.0 should specify an appropriate packetization to carry V.chat.

H.324 support: H.324 should state that terminals supporting V.chat shall support doing so using the “BufferedV.14” or “Transparent Data” data protocols (choice to be determined). The V.42 data protocol may optionally beused to provide error protection. This will keep the development burden small, thereby encouraging V.chat supportby terminal makers.

T.CHAT: Q3/16 should proceed with their “T.CHAT” project, defining it as a T.120 method to carry the V.chatbitstream, but adding multipoint and conference control functions (site ID, etc.) using T.120 series functionality.H.323 and H.324 should state that terminals supporting T.CHAT shall also be required to support V.chat directly ina Logical Channel (LC), so that the direct LC mode is available as a baseline for all multimedia terminals, includingthose without T.120.

H.320 support: For H.320 it is suggested to use the T.CHAT solution in all cases. If enough evidence arrives intime before determination that the simple logical channel based transport is required here also, the appropriate mecha-nisms can be described using H.221 and H.242.

Figure 2 illustrates the three possible modes of V.chat operation on the PSTN. For H.323 and H.310, theappropriate layers would be substituted below the H.245 Logical Channel.

V.CHAT

T.CHAT

T.120

H.245 LC

H.223

H.245 LC

H.223

V.34 V.34 V.18

Figure 2. Three possible modes of V.chat operation.

V.CHAT PSTN OPERATION MODES (ANALOGOUS MODES PLANNED FOR H.323, H.324/I, H.310,H.320)

The goal was to reach an agreement on how to design a standard protocol for text conversation for use with bothwith video telephony and direct PSTN text telephony, and how it should be carried.

P o s i t i o n i n g

Q11-A-17-e (G. Hellström, Omnitor) discusses positioning of text conversation in Multimedia Systems andServices. At SG 16, it was commonly agreed to enhance video telephony to “total telephony” and to support allthree conversational modes: voice, text and video.

The functional goals and the outcome of the discussion in Q3/16 was reviewed. Q3/16 recommends making theprotocol a new T.120 APE (called T.CHAT) and will supply a lighter base, T.Lite, suitable for the services neededby the text conversation. This solution was felt to be architecturally favorable but has the implied risk of still beingtoo heavy for embedded implementations. Two viable alternatives were discussed:



• To use H.245 messages carrying the text information. This was suggested in the Q14/ 16 meeting in Israel. Therisk of clobbering the control channel with text traffic, risking that camera control and other messages are delayedwere regarded as unfavorable and the method was not recommended.

• To use a logical channel, and transfer the text with a simple transport mechanism as described in Q11-A-54r2-e(J. Truman, 8x8). Q11-A-54r2-e proposes a simple AL1 data Channel Format for TeleType/Video-For-The-Deaf; a TeleType capability is indicated in an extension field of the existing DataApplicationCapability sequence,and an SRP option is added to the DataProtocolCapability. This approach was found feasible for point-to-pointcases. The SRP method of transmission was not accepted.

The conclusion was to continue developing the T.120 based T.CHAT as a superset of the solution in a logicalchannel; to introduce mechanisms to select the method at session start up; and to develop a common text protocolV.chat to be used for both cases and also on top of V.18 for pure text telephony.

Text Protocol

Q11-A-54r2-e (J. Truman, 8X8) and Q11-A-12b-e (G. Hellström, Omnitor) present text protocols for thecontents and control of the text dialogue. The UNICODE based Q11-A-12b-e was agreed to be the one tocontinue developing because it has a character set that is standardized and suits a large population. Efforts should beput into keeping the complexity of the protocol extremely low.

NON-CONVERSATIONAL SERVICES (INCLUDING FILE FORMAT)

C. P. Quist of KPN Netherlands was appointed as Chairperson. Q11-A-62-e is the report of the ad hoc meeting.

KPN’s “non conversational services” server was presented. Implementation issues are discussed by KPN in Q11-A-24-e . This H.324 server may be reached at phone number: +31 70 332 40 16; video clips and menus can bebrowsed by sending UserInputIndications. KPN has identified several problems with existing H.324 products,including lack of support of UserInputIndications.

Q11-A-41-e (R. Dubbelink and C. Quist, KPN) identifies markets for non-conversational services and theimplementation aspects of such equipment. Markets identified include: dating service, cinema preview, travelagency, real estate, city information, adult entertainment, flea market, pet adoption, instruction service, and sportsnews. All implementers were urged to support the optional transmission of H.245 UserInputIndication in theirH.324 terminals to support users who wish to use Non-Conversational Services applications.

File Format

Q11-A-42 (C. Quist, KPN) proposes to define a file format for use in H.series terminal applications. The groupagreed that a file format is desirable.

CLOSING PLENARY (WITH Q15/16)

Having not received a formal reply to the last liaison to MPEG4, the group agreed that there was no need to send aliaison at this time. However, it was agreed that D. Lindbergh (PictureTel) will be a co-coordinator to MPEG4(along with C. Hansen, Intel).

Q11-A-16-e , a liaison from SG 12 concerning audio and video performance aspects in multimedia terminals (G.Hellström, Omnitor) was thought to be of value to Q3/16, Q7/16 and Q23/16. It was forwarded to them for theirinformation.

Ad hoc Committees

The group agreed to dissolve the V.8/V.8bis ad hoc, reduce the Testing ad hoc to a coordination effort with theIMTC, where most of the H.32x test activity is now occurring, and establish an ad hoc for Text Telephony. C.Hansen (Intel) and D. Lindbergh (PictureTel) were designated as the coordinators from the Test group to IMTC.



As a result, the following is a table of the active ad hoc committees:

AD HOC COMMITTEE CHAIRPERSONSystem/H.324 D. LindberghH.245 Command and Control C. HansenMobile B. WimmerNon-Conversational Services C. QuistText Telephony G. HellströmSimultaneous Voice/Fax overH.324

I. Sebestyen

In addition Q11/16 members will participate in an ad hoc for Definition of modes, profiles, packetization andcommand and control for H.263+ signaling, set up under the guidance of the Q16/15 Rapporteur, with S. Wenger(TELES Germany) as the Chairperson.

BRIEF REPORT OF Q15/16, ADVANCED VIDEO CODING

G. Sullivan (PictureTel) is the Q15/16 Rapporteur. The report of the meeting is Q15-A-63d1-e. The worktoward H.263+ Decision in January of 1998 is progressing well, and appears to be on schedule. The H.263++extension work has not yet produced concrete draft content. Work is expected to better define the workplan ofH.263++ extensions.

More work is necessary to reach verification and completion of H.263+, and to get it adopted into the appropriatesystems. However, that work is expected to progress. The output draft of H.263+ is Q15-A-60-e (G. Sullivan,PictureTel, editor), the output test model number eight (TMN8) description is Q15-A-59-e (T. Gardos, Intel,editor), and the output draft of preferred mode combinations is Q15-A-57-e (M. Bace, PictureTel, editor). Thisdocument contains a draft list of preferred mode combinations, to allow practical negotiation, structured into three“levels” of support.

These three documents represent the consensus actions made at this meeting. They were generated by the designatededitors in the days following the meeting. No indication has since been received that these documents conflict withthe consensus reached at the meeting on any detail whatsoever, with perhaps one minor exception: P. List (DeutscheTelekom) has reported that in the H.263+ draft (Q15-A-60-e), the prediction of the B motion vector values asdescribed in section 2.2.1.4 should have been initialized to zero rather than half of the P motion vector values whenno motion vector would otherwise be available for use as a predictor. This minor issue will be considered in furtherwork.

H.263L

Q15-A-02-e (M. Zeug, Iterated Systems) presents a review of the activities of the H.263L ad hoc group since theNice meeting (February 1997). The only particular action considered by this group was the consideration of theframe rate specified for the 112 kbps sequence in the set of common conditions, for which the consensus reached bythe ad hoc group was to not change the frame rate specified.

Q15-A-06-e (M. Zeug, Iterated Systems) presents the common conditions agreed upon for H.263L testing.Changes were made to the set of common conditions based upon the liaison statement received from SG 12 (Q15-A-16) and discussions during the meeting. Based on the liaison from SG 12, two additional sequences (Container Shipand News) were added to the set of 10 kbps sequences and one sequence (Silent) was added to the set of 112 kbps se-quences. This brings the number of sequences specified at each bit rate to four as was specified in the liaison fromSG 12. The liaison from SG 12 also indicated that end-to-end delay is an important issue. To that end, it wasagreed to require that H.263L proposals include information on delay performance. Based upon input from theH.263L ad hoc group, it was agreed to add text to the common conditions document to indicate that, in addition tothe mandatory demonstration mode, those submitting demonstration material are encouraged also to present thatmaterial on alternative display technologies representative of those likely to be used in commercial products.

Q15-A-15-e (R. Fryer, University of Strathclyde) is a proposal for modeling delay in video systems using amathematical approach. There was general agreement that this modeling effort would be useful in describing thedelay in H.263L proposals. However, it was noted that the description provided in the contribution was incomplete.It was agreed that an ad hoc group would refine the delay model (chaired by R. Fryer). This ad hoc group will holddiscussions on the advanced video coding e-mail reflector and will present an updated delay model at the nextmeeting.



Q15-A-07-e (M. Zeug, Iterated Systems) is a proposal for a workplan and objectives for H.263L. The groupdiscussed the objectives for H.263L and possible time frames for completing the work. It was agreed that a smallgroup would develop a time line for the completion of the work (see Time Schedule, below).

Q15-A-62-e (M. Zeug, Iterated Systems, editor of the common conditions description) represents the outcome ofthe common conditions actions at this meeting.

PROPOSALS FOR H.263L CONTENT

Two H.263L proposals were presented, including video tape demonstrations. Q15-A-33-e (K. Hibi, SharpCorporation) is a proposal using multimode warping prediction. This work is based upon MPEG-4 core experimentP6. It provides for increased coding efficiency. It was presented as a candidate coding tool for either H.263++ orH.263L.

Q15-A-51-e (M. Karczewicz, Nokia Research) presents the results of experiments conducted by Nokia using theirproposed algorithm. This algorithm was previously presented to SG 15 WP1, Expert’s Group on Very Low BitrateVideo Telephony, February 1997. An analysis of the decoder complexity was presented. Nokia also presented ademonstration of real-time decoding on a 166 MHz Pentium PC. A D-1 tape demonstration compared H.263 PBframe mode with the Nokia proposal utilizing B frame. The group felt that at low bit-rates, the Nokia proposalproduced superior results. At higher bit-rates, the subjective differences were more difficult to observe. It was notedthat the complexity of the Nokia proposal was greater than the complexity associated with H.263, but the Nokiaproposal produced improved video quality.

Both of these proposals are expected to be candidates for H.263L.

RELATIONSHIP WITH ISO/IEC JTC1 SC29/WG11 (MPEG)

Q15-A-19-e (J. Muller, Iterated Systems) presents the results of the coding efficiency work at the April 1997MPEG meeting.

Q15-A-27-e (K. Hibi, Sharp Corporation) presents key discussion points on the relationship between MPEG-4and ITU-T SG 16 Q15. The target of MPEG-4 includes object-based coding, hybrid coding of natural and syntheticimage (SNHC). To achieve these goals, MPEG-4 applies object-based syntax. Therefore, bit stream levelcompatibility with ITU-T H.263+ cannot be expected. Requiring each standard to provide a compatibility mode isnot a complete solution since any compatibility mode is not likely to provide full functionality. Asimplementations move towards software-based solutions, it may be possible to realize dual mode codecs, howeverimplementations become easier if both standards are closely aligned.

The group discussed the alignment issue and determined that there were several technical differences between theMPEG-4 video coding standard and the H.263+ video coding standard. One solution discussed was to influenceMPEG-4 to make changes to their specification to minimize the differences. Another option was to make changesto H.263+ to bring it into alignment with the MPEG-4 specification. After much discussion there was no strongagreement to either create a liaison to MPEG-4 or to modify H.263+. Therefore no action was taken.

H.263L WORKPLAN

A concern was expressed that more research is needed to discover a novel video coding algorithm which can fit intothe H.263L framework. The consensus of the group was that the definition of the requirements for H.263L iscurrently the most important issue to be considered.

H.263L TIME SCHEDULE

It was pointed out that Jan. 98, Nov. 98, Aug. 99, and June 2000 are the possible dates for Determination orDecision of H.263L (assuming that SG 16 meetings are held at regular 10 month intervals). In order to encouragemembers to develop their technologies within the time-span of the schedule, it is essential to make a clear schedule.The group agreed, therefore, to the following tentative time schedule:

• Complete requirements: December 1997

• Call for proposal issued: early 1998

• Evaluation of the proposed technologies: November 1998



Decision will be made whether the proposed technologies have the potential to meet the requirements after thecollaborative effort for improvement by the group. If not, the schedule will be delayed.–Test Model of H.263L (TML1?) defined–The project steps into the collaboration phase towards determination.Note: continuation of the work will be dependent upon the suitability of submissions received.

• Determination: August 1999The result of collaborative improvement will be evaluated again at this point. If it is decided that therequirements are not met, the determination will be delayed.

• Decision: June 2000

REQUIREMENTS FOR H.263L

The group reached consensus that H.263L should support functionalities that cannot be supported by H.263++.However, since the target performance of H.263++ is currently not clear, it was agreed to start the H.263L workwith challenging requirements. Although H.263L should cover various applications including both real-time andnon-real-time applications, it was agreed that a single codec solution should be sought.

The requirements document will be drafted by the H.263L Ad Hoc committee through e-mail discussion. K. Hibi(Sharp), the Associate Rapporteur of Q15/16, was assigned as the editor of this document. The following four itemspointed out in Q15a52 were agreed as the guideline for the work:• The work must focus on the very low bitrate real-time profiles, as indeed this is the most challenging.• Emphasis needs to be placed on low complexity software solutions, as the easiest markets to open will be those

with software only implementation.• Rate control mechanisms must be adaptable, preferably within one codec, between both constant frame rate

modes and variable frame rate modes, depending upon application.• Test material needs to be chosen to reflect the fast motion aspects of true audiovisual source materials, with

many scene changes, pans and tilts, etc.

HANDLING OF THE METHODS ALREADY PROPOSED

The chair expressed concern about how to deal with the methods which have already been proposed for H.263L. Theresponse from the members was that these proposals should be re-submitted with possible improvement after the callfor proposals is issued.

The group agreed that technical proposals/ information before the call for proposals are also welcome, for catchingup with the state of the art.

RELATION BETWEEN H.263++ AND H.263L

The members requested that the work plan of H.263++ be strictly defined and the difference between H.263L andother areas of work be clarified.

The group agreed that a technology proposed for H.263L may be categorized as a candidate technology for H.263++,if the group considers it to be a more preferable place, according to the result of the evaluation for the proposal. It isexpected that proposals for H.263++ will maintain the H.263 syntax. Proposals for H.263L are not required tomaintain the H.263 syntax.



Q11/16 AND Q15/16 MEETING ROSTER, JUNE 24 – 27, 1997, PORTLAND, OR

Tom Geary, Rockwell Q11/16 RapporteurGary Sullivan, PictureTel Q15/16 RapporteurHost: Intel

8X8 Barry Andrews8X8 Chet GrahamAcer Advanced Labs Reuven AcknerAethra Telecom Roberto FlaianiBellsouth Cellular Saurel QuettanBT Mike WhybrayCCL Tzu-Hsin WangCCL Industrial Tech. Li-Feng Lai

Research InstituteChromatic Chad FoggCOMSAT SimaoCampos NetoDelta Info. Systems Richard SchaphorstDeutsche Telekom Peter ListEricsson Radio Goran BangEricsson Telecom AB Rickard SjobergErisson Mickey NasiriErisson Telecom AB Magus JandelESS Technology Yuhai MaoFrance Telecom Patrick BoissonadeFrance Telecom/CNET Bruno LoretFujitsu Laboratories Akira NakagawaHitachi Yuichiro NakayaHitachi America Naiqian LuImageCom Dr. John MasonINMARSAT Eyal TrachtmanIntel Tom GardosIntel Jay GilbertIntel Chris HansenIntel Karl LillevoldIntel Fernando MartinsIterated Systems John MullerIterated Systems Michael ZeugKPN CorQuistLinkoping University Haibo Li

Electrical EngineeringLucent Goran DjuknicLucent Ryan HolmqvistMatsushita Yutaka MachidaMIT Christer EnglundMotorola James BraileanMotorola Timor KadirMotorola Kevin O’ConnellNokia Mobile Phones Frank FuNokia Research Center Petri HaavistoNokia Research Center Matti HarmovaaraNokia Research Center Marta KarczewiczNokia Research Center Marko LuomiNokia Research Center Jouni Salonen

NTT Yashiro TomitaNTT DoCoMo Toshiro KawaharaOKI Toshisa NakaiOKI Electric Industry Masaki KameyaOmnitor Gunnar HellstromPhillips Jerome FournierPictureTel Matthew BacePictureTel Suneel BhagatPictureTel David LindberghPictureTel John SieversPictureTel Gary SullivanProgressive Networks Dr. Gary GreenbaumProgressive Networks Alan LippmanRobert Bosch GmbH Peter VogelRockwell Semiconductor Anurag BistRockwell Semiconductor Tom GearySamsung Electronics Dong-Seek ParkSamsung Electronics Jeong Hoon ParkSharp Corporation Heiichi HibiSharp Digital Info. Kai SunSharp Laboratories Shawmin LeiSharp Laboratories Kristine MatthewsSharp Laboratories Jordi RibasSiemens Istvan SebestyenSiemens Bernhard G. WimmerSiemens AG Dr. Andre KaupSmith Micro Software Paul LongSmith Micro Software Robert McKenzieSorenson Vision Chien-Min HuengSorenson Vision Kyminh LiangTelefonica Pedro CrespoTelenor Satellite Services Gisle BjontegaardTeles AG Stephan WengerTelia Research AB Ola AndersonTelnor R&D Gunn Kristin KlungsoyrThomas Multimedia Michel KerdranvatToshiba Hirokazu TanakaToshiba Osamu YamagishiUCLA John VillasneorUCLA Electrical Eng. Greg KamosaUCLA Electrical Eng. Michael SeveraUniv. of British Columbia Guy CoteUniv. of Strathclyde Richard FryerVTEL Dan KlenkeVTEL/CLI Sen-ching CheungVxtreme Yiu Fai WongXirlink Vladimire AlekseyevXirlink C.C. Chou



REPORT OF Q18/16, INTERACTION OF HIGH-SPEED VOICEBAND DATASYSTEMS WITH SIGNAL PROCESSING EQUIPMENT IN THE GSTN

JUNE 26 – 27, 1997, AMSTERDAM, THE NETHERLANDSJOINT RAPPORTEUR GROUP-GII

AM-18/16-04 (J. Magill, Lucent, SG 16 WP1 Chair) is extracted from the draft Report of JRG-GII. J. Magillexplained that the work of the JRG-GII originally had little effect on the work in SG 16. However, at a recentmeeting of the ITU-T Study Group Chairmen, it was agreed that future work related to the Internet would becoordinated under the umbrella of the GII project. Accordingly, three Internet related projects were defined as follows:

Project I.1 Overview of Internet related issues led by SG 13Project I.2 Multimedia over IP led by SG 16Project I.3 Interaction between Web Services and PSTN/ISDN led by SG 13.

Within SG 16, the coordination of activities will be carried through Q16/16 and Q17/16 which report directly to theStudy Group Chair, while the technical work will be done within the relevant questions.

ETSI TIPHON

G. Meyer (Siemens, Secretary of ETSI’s TIPHON project: VoIP to PSTN/ISDN/GSM Interoperability) presentedETSI’s TIPHON project as described in AM-18/16-03 (Terms of Reference) and AM-18/16-11(Presentationfoils). The terms of reference of the project cover the following aspects:

1. Requirements for service interoperability, including the technical aspects of billing2. Reference configuration and functional models3. Call establishment and clearance4. Address translation5. Security6. End-to-end quality of service aspects, including transcoding and echo cancellation.

The work is divided in three phases with the first phase expected to finish by December 1997. The objective is tointernetwork voice from an Internet user to users of the PSTN/ ISDN/GSM. One important characteristic of theproject is the plan to implement and build demonstrations of interoperability. The work will be carried by sixworking groups.

G. Meyer indicated that TIPHON is open to contributions worldwide. They have scheduled a TIPHON meeting inBoston September 26 - 30, 1997, and would like to coordinate its activities with the ITU.

It was noted that ETSI’s project TIPHON is very similar to GII project I.2 led by SG 16. Therefore, strongcommunication and cooperation will facilitate the advancement of work in both organizations within the tightschedule specified.

TEXT CONVERSATION

The Rapporteur (M. H. Sherif, AT&T France) presented the draft requirements for text conversation in AM-18/16-08 (G. Hellström, Telia, Q9/16 Rapporteur). This is relevant to the Q18/16 work because it defines services toprovide manual or automatic translation among the various modes (e.g., between text and speech, text in onelanguage to text in another language, or combinations of the above in a conference mode). Although the impetus forthe work in Q9/16 is telephony to the hearing-impaired, the same mechanisms could be used to provide multimediaon IP or to enable the interaction of web services and the PSTN/ISDN (GII draft projects I.2 and I.3).

IETF PROPOSED COMPRESSION ALGORITHM

G. Mamais (National Technical University of Athens) was invited to the meeting by AT&T. He presented AM-18/16-05 and AM-18/16-07 (Analysis and Examination of the IETF Proposed Algorithm for Compressing theRTP/ UDP/IP Headers, paper and presentation foils, respectively). The IETF proposed compression algorithm isimplemented below the IP layer. Header compression is to be used on point-to-point links;compression/decompression processing takes place on the routers which are at the endpoints of those links. TheIETF algorithm can increase the bandwidth utilization for speech traffic from 33% to 80-90% at the expense of thepotential problems of rejecting a large number of sequential packets. This can be a problem for speech packets.Another minor problem is that it adds some jitter to packets (however, this is not significant compared to the



Internet delays). The participants felt that these contributions contain important results that should be shared withQ13/16 and Q14/16, and with the speech quality experts of SG 12. They suggested that AT&T resubmit thecontributions to the meeting of WP1/16 and WP2/16 September 12. AT&T agreed to consider it.

VOICE AND DATA MULTIPLEXING

AM-18/16-09 (L. Lucena, AT&T Labs) compares two different techniques for multiplexing voice and data trafficover low-speed point-to-point links. It compares V.76 with explicit and implicit suspend/resume mechanisms. TheV.76 approach can accept large amounts of data thereby avoiding the problems with the RTP/UDP/IP approach. Theparticipants felt that this contribution is useful and should be communicated to the experts of Q8/16. J. Magill, asthe WP1/16 chair, agreed to provide this contribution at the next meeting of Q8/16 (see report in this issue of CSR-T).

The participants agreed that there are at least two techniques to multiplex voice and data efficiently :• H.324/H.223• V.70/V.76 (with the suspend/resume enhancements).Contributions are needed for comparing the two approaches to advance the work on multiple calls interfacing thePSTN.

Several questions were raised on whether the multiple calls capability could pose significant competition to ISDN.However, it was clear after discussion that:• This feature can be used to provide some (and not all) ISDN capabilities wherever ISDN is not available• It may be needed before ISDN is widely deployed to provide new services that combine real time and non-real

time interactions (e.g., shopping through the Internet)• The data rate for this technique is limited to 33.6 kbit/s (or at best 56 kbit/s) and cannot go to higher data rates• The demodulation/remodulation causes additional delay (about 100 ms for each demod/ remod) that may degrade

speech quality.

H.246

The Rapporteur (M. H. Sherif, AT&T) explained the agreements reached at the March meeting of SG 16 oncooperation with Q13/16 and Q14/16. More specifically, the experts of Q18/16 will provide the editor of H.246 (M.Reid, PictureTel, Interworking of H.Series Multimedia Terminals, and H.Series Multimedia Terminals and VoiceOnly Terminals on GSTN and ISDN) the necessary requirements for the interface with the PSTN. This interfacewill constitute Annex B of H.246. Accordingly, M. H. Sherif presented the new version of H.246 (AM-18/16-06©).

The participants suggested several improvements to H.246. However, it was not clear to all participants whatQ18/16 was supposed to do to progress the work of H.246. (Reporter’s note: most of the participants at the Q18/16meeting were not present at the March meeting of SG 16). Improvements suggested:• In the title, change voice only terminals to voice/voiceband terminals.• In the summary and the first paragraph of the Scope:

– Interworking units and adapters are not defined. Are they the same or different?– It is not clear why interworking units are not network gateways.– Does the GSTN include mobile voice networks such as GSM?– Does the GSTN cover the case of voice-only terminals connected to mobile networks?

• The second paragraph of the scope is not clear. It was suggested to mention clearly that the interworkinginvolves two aspects:– Interworking of the various H.series units with the network acting transparently. This is discussed with

Figures 1-3 of H.246.– Interworking of H.series terminals to provide web-oriented services that interact with existing terminals

connected to the PSTN. Some reference figures are needed to explain the type of interoperability that isenvisioned.

• It should be mentioned in the text before Table 1, that the interworking scenarios are for H.series terminals.• In Table 2, the title of the first column should be Voice/Voiceband terminals on the GSTN. Add also to this

table, interaction with voice-only mobile.

AM-18/16-10 contains a strawman proposal for Annex B of H.246, based on the text that the editor of H.246 hasproposed and the text of TD-23(GEN), Signaling for Multiple Calls on the PSTN (M. Sherif, AT&T, US) fromthe SG 16 meeting in March 1997.



The Q18/16 meeting reviewed the scenarios for interworking between H.323 systems/terminals, and GSTN basedsystems/terminals. As a result, it was proposed that specifications for the following interworking scenarios bedeveloped and documented in Recommendation H.246:

Interworking between H.323 systems/ terminals, and:

1. Speech only GSTN terminals2. H.324 terminals on the GSTN3. Multi-call applications on the GSTN (as defined below)4. V.70 terminals on the GSTN (as identified in H.323)5. Voiceband terminals on the GSTN

Note: This list does not explicitly include mobile terminals (both multimedia and speech only). These should beaddressed if they are not generically included in the GSTN cases.

The following is a more detailed analysis of these applications and issues that need considerations.

Speech Only GSTN Terminals

The “Speech Only GSTN Terminals” application involves the interconnection of regular telephone terminalequipment with IP-based telephony in both call originate and call answer applications. The full definition of thisapplication is currently expected to be within Annex B to H.246. This definition will be developed in conjunctionwith SG 16 work to co-ordinate all ITU-T activities on IP- based telephony interworking, and the GII Projects I.1and I.2. Close co-ordination is expected with the ETSI Project TIPHON.

H.324 Terminals on the GSTN

The “H.324 Terminals on the GSTN” application considers the interworking of H.324 multimedia terminals on theGSTN with H.323 terminals on IP-based networks. It involves any necessary speech or video trans-coding anddefinition of call control procedures etc. It is expected that this will be a future Annex to H.246.

Multi -Cal l Appl icat ions on the GSTN

Multi-call applications support several calls simultaneously on a single GSTN line. For example, IP connectionscan be maintained on a data channel, while leaving a voice channel available for traditional GSTN use. This ap-plication requires an efficient multiplexer on the GSTN link; the multiplexing schemes of H.324 and V.70 (or both)are candidates. (Note: H.225.0 is not considered to be acceptable, even with compression of the header information.See AM-18/16-05 , above).

Issues which require consideration include but are not limited to:− Selection of the multiplexing technique− Whether this capability is offered all the time or only on an as needed basis− The implications of delay on the GSTN quality of service− Location of the adaptor with respect to the exiting network elements

It is proposed that the general solution of the multiple call capability be in a separate recommendation under Q18/16.The special case of H.323 terminals will be documented in Annex B of H.246.

V.70 Terminals on the GSTN (as ident i f ied in H.323)

The interworking of V.70 terminals to H.323 is within the scope of Annex B of H.246.

Voiceband Terminals on the GSTN

Voiceband Terminals on the GSTN may require further definition to handle fax signals.

Based on the above, the feeling of the participants is that Annex B may not be ready for approval at the January 1998meeting of SG 16.

Mostafa Hashem Sherif, AT&T France



Q18/16 MEETING ROSTER, JUNE 26 – 27, 1997, AMSTERDAM, THE NETHERLANDS

Mostafa Hashem Sherif, AT&T France Q18/16 RapporteurHost: AT&T

AT&T Mostafa Hashem SherifAT&T Romeo ZwartFrance Telecom Gérard DupinKPN Research Marsh van DortLucent Technologies John MagillNat’l Tech. Univ. of Athens George MamaisSiemens Gerald Meyer

REPORT OF SECOND ETSI PROJECT, MULTIMEDIA TERMINAL ANDAPPLICATIONS, JUNE 30 - JULY 4, 1997, SOPHIA ANTIPOLIS, FRANCE

ETSI’s Multimedia, Terminal and Applications group (MTA) has adopted a single numbering scheme at its lastmeeting; there will be no distinction between Permanent Documents, Temporary Documents and WorkingDocuments. ETSI/MTA-97-02 (ETSI Secretariat) contains a list of all MTA documents.

ETSI/MTA-97-131 (ETSI Secretariat) is the attendance list of the second MTA meeting. Attendance was small,only sixteen people. It was expected that the merger of former Terminal Equipment (TE) 1, TE 2 and TE 4 wouldlead to a group of roughly 60 people. It appears that members of ETSI are waiting to see the work program of MTAbefore they send their experts to its meetings. R. Rüggeberg (Deutsche Telekom AG) proposed establishing a well-defined MTA work program for the two coming years to attract expert contributions. If future MTA meetings do notdraw larger expert participation, it will have to be discontinued.

J. Meredith (ETSI Secretariat) will continue to act both as ETSI Technical Officer and MTA Secretary.

On the recommendation of MTA Chair, two Vice-Chairmen were elected by acclamation, both former TE1Chairmen: H. Layec (France Telecom) and K. Sambor (Post Telekom Austria).

Four Working Groups and an ETSI Project MTA Management Group were established. The following rapporteurswere nominated and will be confirmed at the next MTA meeting:

• WG1: H. Layec (France Telecom)• WG2: I. Sebestyen (Siemens) will nominate M. Blaschitz (Infonova)• WG3: M. Blaschitz (Infonova)• WG4: To be Determined

ETSI/MTA-97-113 (B. Larisch, Deutsche Telekom AG) describes Multimedia (MM) Work Items which arebehind schedule. Digital Video Coding (DVB) systems above 10 GHz, text telephony and video coding for very lowrate and ATM environments are noted. ETSI/MTA-97-125 (K. Sambor, Post und Telekom Austria) discussesthe monitoring of ETSI Multimedia Work Items (Retrieval), and provides a list of late projects. ETSI/MTA-97-127 (M. Breidthardt, IBM) discusses monitoring of ETSI Multimedia Work Items (Common Blocks).ETSI/MTA-97-129 (J. Meredith, ETSI Secretariat) contains the MTA Work Program, for information.

A number of rapporteurs indicated that they are unable to pursue their duties due to a change in their company’sinterests or a change in their own activities within their companies; as a result the MTA work program was modifiedquite extensively. The remaining work items are listed in Table 1, below; numbering reflects assignment to thenewly created working groups. A number of new work items were proposed as candidates to be agreed at the nextMTA meeting.

STRATEGIC PLANNING

ETSI/MTA-97-132 (H. Lochs, R. Koenen, K. Rijkse, KPN Research) provides an overview of the H.xxx, T.1xxand MPEG standards, and identifies areas (information retrieval, interworking and LAN gatekeepers) where additionalwork is desired. The contribution was introduced by K. Sambor (Post und Telekom Austria AG) as information; itwas not discussed.



Work Item Reference Title StatusDES/MTA-01n001 MPEG related APIs work not yet startedDE/MTA-011057-2 Use of DSMCC for basic multimedia

applicationsPublic Inquiry

DES/MTA-011074 API for DAVIC Service Information Stable draftDEN/MTA-024045 Text telephone terminal Awaiting EP approvalDTR/MTA-024121 Text conversation facility in the T.120

environmentStart of work

DEG/MTA-034122 Inter-working between H.32X terminals AdoptedDTR/MTA-032034 Generic PCI for Multimedia applications

(Identification of PCIs needed)Awaiting EP approval

DES/MTA-041066 File transfer profile, B-channel aggregation andsynchronous compression

Stable draft

DE/MTA-042023 Joint synchronous editing, joint documentpresentation/viewing

PE Comments resolution phase

Table 1. MTA Work Items.

ETSI/MTA-97-137 (K. Sambor, Post und Telekom Austria AG) outlines the following items for strategicplanning:

• ITU-T SG 16 items, e.g., review T.120Lite• ISO SC 29 MPEG-4• Internet Engineering Task Force (IETF)• DAVIC; call for proposals• H.245 versus Digital System Multimedia Communication Controls/Multimedia Integration Framework

(DSMCC/DMIF)• Multimedia Middleware (CORBA + JAVA)• 3-D, Virtual Reality, Simulation

MTA should also support European industry, including unified positions to the ITU, and support development ofMultimedia Applications Usage.

The new ETSI Project MTA Project Statement:Management working group will monitor MM ongoing work, identify those “niches” and more generally act as aforerunner of MTA activities.

ITU-T SG 16 L IAISON

ETSI/MTA-97-096 (K. Sambor, Post und Telekom Austria and I. Sebestyen, Siemens AG) provides an overviewof the first ITU-T SG 16 meeting (March 17-27, 1997); it includes an excellent tutorial on the organization of SG16, its main questions and planned output. Some ETSI/MTA delegates felt that standards should come from Europefirst; others felt that ETSI/MTA should focus on harmonization of standards. It was also clear that each ETSImember should continue to have its own vote within ITU-T while trying to have Europe speak in a single voice. K.Sambor (Post und Telekom Austria), I. Sebestyen (Siemens AG), R. Rüggeberg (Deutsche Telekom) and others whoattend SG 16 meetings could serve as liaisons.

The following were provided for information:• ETSI/MTA-97-134 , Draft Recommendation H.246, Inter-working of H.Series multimedia terminals (ITU-T

SG 16)• ETSI/MTA-97-135 , a primer from DataBeam on H.323 (Post und Telekom Austria)• ETSI/MTA-97-141 , a draft of ITU-T Recommendation T.170, Framework of the T.170 series

recommendations (MHEG-1,3,5 with APIs and DAVIC API), (K. Sambor, Post und Telekom Austria)Discussion on these contributions focused on how ITU-T Recommendation H.323 can be approved, when it dependson Real Time Transport Protocols (RTP) which is not stable; and how audiovisual terminals in ITU-T work on“unreliable” networks.

ISO SC 29 LIAISON

• ETSI/MTA-97-115 , Contribution to SWG-GII (ISO/IEC JTC 1/SC 6/WG 1), lists JTC1 SC 6/WG 1’scurrently available and planned standards for implementing GII services.



• ETSI/MTA-97-116 (JTC1) notes the need to make changes in the JTC1 processes for greater responsivenessto market requirements.

IETF L IAISON

ETSI/MTA-97-133 (Post und Telekom Austria) is the latest version of Internet Draft Resource ReservationProtocol (RSVP). It is not a formal liaison from IETF but was provided for information.

TIPHON LIAISON

ETSI/MTA-97-126 (K. Sambor, Post und Telekom Austria) is a summary report of the first EP-TIPHONMeeting. A copy of this report is available at http://www.etsi.fr/tiphon.

DAVIC LIAISON

ETSI/MTA-97-145 (M. Blaschitz, Infonova) is DAVIC’s ninth call for proposals (technologies for IP basedsystems).

DAVIC Digital Video Broadcasting (DVB) Project Group

ETSI/MTA-97-144 (G. Wahlberg, Nokia Consumer Electronics), a copy of EC COM (97) 152 final, discussesthe competitiveness of the European Union Information and Communication Technologies (EU ICT) Industry. G.Wahlberg indicated that a number of his company’s experts participate in Digital Video Broadcasting (DVB) work.

ETSI/MTA-97-119 (H. Poulsen, Tele Danmark) notes that Europe’s cable TV groups have agreed on a standarddecoder (Eurobox) based on the Viaccess system developed by France Telecom. In the UK, Cable and Wireless andTelewest, together having 66% of UK market, have chosen a General Instrument developed system.

STQ (SPEECH TRANSMISSION QUALITY) LIAISON

ETSI/MTA-97-128 (ETSI TC/STQ) is a liaison statement from the Technical Committee/ Speech Processing,Transmission and Quality Aspects (TC/STQ) to ETSI/MTA. It notes that they provide a focal point within ETSIfor all issues relating to end-to-end speech quality.

ETSI/MTA-97-138 (ETSI Secretariat) is correspondence from Basic Inter-operability for Terminals for TelematicServices (BINTERMS) to ETSI/MTA. The intent of this consortium in the field of multimedia is to developconformance tests of T.120 implementations. BINTERMS’ offer to use ETSI as a channel to disseminate its resultsin Europe is most welcome. Conformance may be established by running compatibility tests of different equipmentrather than a detailed conformance test plan.

MARS LIAISON

ETSI/MTA-97-109 (M. Blaschitz, Infonova) is an informal liaison statement from MARS to ETSI MTA. TheMARS project will provide a multimedia client-server implementation targeted to the SOHO (small office, homeoffice) environment, using DAVIC specifications, in particular DSM-CC. The MARS project main objective is toprovide feedback and input to the standardization organizations.

TC-HF LIAISON

ETSI/MTA-97-99© (Telefonica de Espana) is draft DTR/HF-01037, Human factors in multimedia informationretrieval services, from the ETSI Technical Committee for Human Factors (TC-HF). The draft is expected to beapproved at the HF meeting in September 1997.

SMG4 LIAISON

ETSI/MTA-97-101 (Special Mobile Group 4) is a liaison statement on Global System for MobileCommunications-Application Programming Interfaces (GSM-API). ETSI/MTA-97-102 (J. Meredith,ETSI/MTA Support Officer) is a proposed response to the liaison from SMG4 concerning GSM-API.

SMG4 depended on TE2 to define their API based on the ISDN API. ETS 300 325 edition 2, which defines thisISDN API, refers to two APIs (PCI [Programmable Communications Interface] and Common API [CAPI]) anddefines two profiles. The new ETS, Harmonized Programmable Communications Interface (HPCI), will have adifferent number (ETS 300 838) than the first edition. SMG4 will pick up one of the two profiles for its GSM API.



ETSI/MTA-97-142© (M. Frey, BVB) is the edited draft (changes only) of ETS 300 325 ed. 2 showing the changesproposed; the contribution was tabled without any discussion.

SECURITY LIAISON

ETSI/MTA-97-118© (ETSI Board) is the ETR Security Techniques Advisory Group (STAG) guide to ETSI securitystandards policy. This ETR is a guide to the documents being prepared by STAG.

REPORT FROM THE ETSI SECRETARIAT

ETSI/MTA-97-121© (ETSI Secretariat) is draft ETS 300 498-2 (ODA Communication Services, Joint synchronousediting, joint synchronous viewing), PE version. ETSI/MTA-97-120 (ETSI Secretariat) provides Public Inquiry(PE) comments on ETS 300 498-2. France, noting that the area has little market interest, and Spain did not acceptthe draft ETS.

ETSI/MTA-97-149 (ETSI/MTA) outlines the program of work for EP MTA. ETSI/MTA agreed to the creationof the following working groups (basically as proposed by Austrian Post und Telekoms) and assigned to eachworking group candidate new work items (WI):

WG 1: Multimedia Terminal Application Architecture Proposed New Work Items

• Framework for a software architecture for multimedia applications. This work item includes definition of asoftware architecture for multimedia terminals and applications based on ETSI/MTA-97-147© (M Blaschitz,Infonova).

• Telephony API. This API for embedded systems provides telephony relating functions, e.g., dialing for publicnetworks and Internet.

• Persistent storage API. This API provides access to persistent storage devices in embedded systems, e.g., a SetTop Box with a hard disk.

• Security API. This API allows applications to use security services offered by security modules. The API shallcover channel security as well as chip card security. The API shall be abstract enough to base itself on differentsecurity implementations; however no details of the security implementations shall be exposed to the usingapplication. The definition of the interface shall follow a detailed analyses of the application requirements.

• Multimedia and Hypermedia Expert’s Group (MHEG)-5 Conformance Testing. This work item includesdefinition and production of minimum set of conformance testing objects for MHEG-5. These objects constitutetest suites to check the correct dynamic behavior of an MHEG-5 engine as defined by ISO/IEC 13522-5 coded toETS 300 777-1. The test suite shall also allow checking of conformance of an MHEG-5 engine to itsapplication domain definition (expressed as a set of options and tag values as defined by ISO/IEC 13522-5),considering especially the application domain definition for DAVIC. Note: For this proposed new Work Item,three supporters are available; one more is needed, according to ETSI rules, for the work to start.

• Mobile Terminal Applications. This work item includes dynamic allocation of applications and external servicesfor GSM.

• Mobile Internet. The goal is to standardize a set of tools and protocols to enable Internet applications such as theWorld Wide Web to operate seamlessly in a mobile environment. The first stage of standardization will cover theGSM networks and rapidly enable the Network operators to offer Internet services. Optimized Internet packagesfor the transport and coding over mobile networks, e.g., Mobile Transfer Protocol, Mobile Markup Language, aswell as other modules, will be standardized. ETSI/MTA-97-148 , a detailed presentation prepared by Ericsson,Nokia and supported by the computer industry (IBM, Digital), was given for SMG4, which thought it was notthe right committee to do the work. A similar presentation will be requested for the next meeting of ETSI/MTA.

Further stages will evolve into the support of full multimedia for the next generation of mobile networks.

WG 2: Mult imedia Terminal Aspects for Real Time Applicat ions (Conversational & DistributionServices) Proposed New Work Items

• Quality of Service (QoS) Investigation - switched Internet. This work item studies the combination of Next HopResolution Protocol (NHRP), Resource Reservation Protocol (RSVP) and ISDN in order to provide a switchedQoS-shortcut for real time traffic.



• H.324M “European profile,” especially for GSM and Digital European Cordless Telephone (DECT). ITU-TH.324 M is being standardized by the ITU-T SG 16. ETSI/ MTA-97-150 (I. Sebestyen, Siemens) describesthe current work in the ITU-T on H.324 Mobile. Final approval is expected in January 1998. The current draftof H.223 has converged on a multilevel multiplex structure. This multiplexer has four levels (plain H.223 = 0and Annex A-C), representing progressively more robust, and more complex approaches. The reason for thecomplex multiplex structure is twofold: easier inter-working with non-mobile H.324 platforms, and avoidance ofoverly complex trans-coding (see also the Multimedia Aspects for Mobile Terminals Work Item under WG 3).The ITU-T had to take into account all possible mobile platforms (including North American and Japanese).

In Europe, the “near term” wireless multimedia solutions will be DECT for the cordless Multimedia Platform andGSM for the mobile Multimedia Platform; the “long term” solution will be Universal MobileTelecommunications System (UMTS), still a few years away.

For DECT and GSM, the appropriate H.223 mobile multiplex stack(s) has to be selected, allowing bestperformance at optimal terminal complexity both between the same mobile terminal types (DECT or GSM) - thesubject of this work item - or between the mobile terminal (DECT or GSM) and any other type of MM Platform(DECT, GSM, PSTN, ISDN, IP...) - see Multimedia Aspects for Mobile Terminals Work Item under WG 3.

H. MULTILINK is being prepared by the ITU-T SG 16 as a new type of “Channel aggregation” (Target date: End1998). Whether H.MULTILINK is also suitable for DECT and GSM remains to be studied. This topic isespecially important for GSM, as current bandwidth limitation of GSM would require the use of at least twosimultaneous channels for H.324 M.

As enhancement of the new ITU-T H.263+ Video standard (Final approval: January 1998), a number of newoptions are defined. Some of them are especially suitable in a Mobile environment (layered coding, selective errorrobustness, etc.). The task would be to study the H.263+ video options and define a “mobile H.263+” profile.

• T.39 European profile. ITU-T T.39 (in ITU-T SG 8) defines a multimedia terminal standard that simultaneouslysupports point-to-point facsimile and speech transmission. Such an application is particularly useful in a homeenvironment, where often no separate facsimile device exists, where no second PSTN line is installed forfacsimile, where transmission cost is a sensitive factor, and where the need for simultaneous point-to-pointfacsimile and speech transmission is high.

In the ITU-T T.39 specifications, three incompatible PSTN transports were defined: H.324 (PSTN Videophone),V.70 (DSVD Terminal), and V.61 (ASVD Terminal). There is no direct interworking possible between the threetransports. In T.39, the common “fallback mode” is plain T.30 Facsimile, which does not allow the simultane-ous carriage of voice and data. Since ETSI is not bound to the political decision of the ITU-T, it is possible todefine a “European T.39 profile” that is based only on one PSTN transport.

• H.324/I; H.dispatch (V.108) - Second generation ISDN MM Terminals. The ITU-T is working on a secondgeneration ISDN MM Terminal that is characterized by the above standards. ETSI has appropriate standards forthe First generation (which does not yet cover several improvements already adopted in H.320 improvements,such as H.263 as optional video coder, and G.723.1 as optional speech coder). It may be necessary to monitorthe ITU-T work, contribute to it, update the First generation H.320 and maybe specify a Second generation ETSIISDN MM standard (even if very short, referring to ITU-T recommendations, and specifying some “European”specifics). It would be necessary to certify that the very sensitive migration from the First to the Secondgeneration does protect past customer investments and has only positive effects on the N-ISDN conversationalmultimedia market.

• Broadband Multimedia Terminals. It is expected that a concrete Work Item proposal will be made available at thenext EP-MTA meeting.

WG 3: Services Integration and Inter-working Proposed New Work Items

• Inter-working between H.323 Terminals and H.324 / H.324M / H.324I Terminals. This WI (Work Item) willinvestigate the Gateway function between the Internet and PSTN/ ISDN/GSM for the multimedia case based onthe results of the EP-TIPHON for voice only.

• Hypermedia messaging. The X.400 series recommendations (1996) support multimedia messages (text, voice,video); however the real operation in a “multimedia/hypermedia” fashion is not yet standardized either in ITU-T/ISO or in the relevant Internet RFCs. In some scenarios, it is desirable to not always transmit the multimediacontent as part of the message, but to provide hyperlink functionality.



Therefore it is proposed in ETSI/MTA-97-103 (M. Blaschitz, Infonova, and K. Sambor, Post und TelekomAustria) that an integration of message services and multimedia retrieval services be defined in such a way thatmultimedia contents are only transmitted on demand. This is applicable to X.400 and SMTP-MIME (SimpleMail Transfer Protocol-Multipurpose Internet Mail Extension) in relation with Internet and DAVIC compliantsystems. This will allow hyperlinks from X.400 to Internet Server, X.400 to DAVIC/DSMCC Server, Internetmail to Internet Server, and Internet mail to DAVIC/DSMCC Server.

• Multimedia Multi Service Terminals with T.120, T.130, T.170, X.400, X.500 functionality based on H.310Asynchronous Transfer Mode (ATM) Terminal. ITU-T SG 16 has not yet discussed solutions which are based onH.310 native mode ATM-Terminals, but take also into account X.400, X.500. There is new work on a “T.120Lightweight profile” for audiovisual applications.

• Multimedia aspects for mobile terminals. This Work Item is related to Work Item H.324M “European profile”under WG 2. This section defines work for service integration and inter-working with other MM networkplatforms, such as GSM, DECT, PSTN, ISDN, IP, and ATM. The ETSI/MTA tasks defined in WG 2 work itemapply. In addition, study and specification of MM channel setup for PSTN, ISDN, DECT and GSM will benecessary. In H.324 (PSTN), this specification is done via V.8/V.8bis; in ISDN, via HLC/LLC Codes and thenew ITU-T H.dispatch (future V.108) Recommendation.

WG4: CDH and File Transfer Proposed New Work Items

A candidate new Work Item on Cooperative Document Handling (CDH) is anticipated for the next EP-MTAmeeting.

PUBLIC INQUIRY (PE) COMMENT RESOLUTION

Due to lack of experts, the PE comment resolution was postponed to August 1997.

SPECIALIST TASK FORCE USE

ETSI/MTA-97-065©, M. Blaschitz (Infonova), prETS 300 777-2 - End-to-end protocols for multimedia informationretrieval services; Part 2: Use of Digital Storage Media Command and Control (DSM-CC) for basic multimediaapplications, is approved to go to Public Inquiry.

NEW PROJECT TEAM

ETSI/MTA-97-091 (H. Creff) contains proposals for extension of PT90, developed interface from JAVA VM toDAVIC DVB Service Information (SI).

ETSI/MTA-97-092 (H. Layec, France Telecom) contains terms of reference for a project team on “ConformanceTesting for MHEG-5.”

These contributions produced animated discussion. On one side, some felt that technical work should start withinETSI/MTA, that experts should attend ETSI/MTA meetings, and that Project Teams now called Specialist TaskForce (STF), should only occur in exceptional urgent situation; also MTA should not be a management committeeof project teams. On the other side, some indicated that the work has become so detailed that progress cannot bemade in a meeting such as ETSI/MTA, and that work can only be progress in an STF environment. The meetingwas totally split on this issue. The following agreement was reached: due to the urgency of asking for STF funding,it was agreed to proceed with the request for funding for those STF, to review the situation at the next MTA meetingand to cancel the request at that time if sufficient experts attend the MTA meeting and progress the work. It wasnoted that the work item on Conformance Testing for MHEG-5 is lacking the support of a fourth ETSI member; itis not yet an approved Work Item.

OTHER BUSINESS

ETSI/MTA-97-139 (B. Skinner, BT) contains comments on ETS 300 807 deals with Pulse Code Modulation(PCM) coding law of audiovisual terminal equipment. ETSI/MTA did not agree with the changes proposed and sug-gested that the same comments be addressed to the ETSI Digital Terminal and Access (DTA) Project.

ETSI/MTA-97-136 (Post und Telekom Austria AG) discusses the NO PROBLEM progress report (NOnPROprietary reliaBLe Electronic Mail). K. Sambor (Post und Telekom Austria) informed ETSI/MTA of theongoing work in his organization to develop an electronic mail that does not suffer from the numerous incompatibil-ities found in exchange of documents; thus the acronym “no problem.”

Jacques A. Besseyre, Telecom Consultant



ETSI/MTA ATTENDANCE ROSTER, JUNE 30 – JULY 4, 1997, SOPHIA ANTIPOLIS, FRANCE

Rolf Ruggeberg, Deutsche Telekom AG MTA Chairman

BT Malcolm McGovernBT Brian SkinnerBVB Matthias FreyDeutsche Telekom AG Birgit LarischDeutsche Telekom AG Rolf RuggebergETSI Secretariat John MeredithEutelsat Alain MearFrance Telecom Herve LayecInfonova Michael BlaschitzKPN Jean Henri KiekboschMotorola Mark GrubbNokia Consumer Elec. Goran WahlbergPost und Telecom Austria Robert HadererPost und Telecom Austria Klaus SamborParadyne International Jacques BesseyreSamsung Electronics John B. FennSiemens AG Istvan SebastyenTele Danmark A/S Henning Poulson

REPORT OF Q4/16, Q7/16, Q8/16, AND Q23/16 RAPPORTEUR’SMEETINGS, JULY 7 – 11, 1997, DUBLIN, IRELAND

Q4/16, V.8BIS

Subjects addressed at the Q4/16 meeting included revisions to V.8 and V.8bis, corrections to the V.8/V.8bisImplementer’s Guide, and V.dispatch. The meeting was chaired by L. Brown (Motorola).

LIAISON

G. Griffith (Rockwell) presented V8bis 03 , a liaison from Q1/8 (Facsimile Terminals) concerning proposed draftRecommendation T.66 (T.codes). The liaison discusses two issues. First, Q1/8 requests an editorial correction tothe wording in Table 3/V.8 of the V.8/V.8bis Implementer’s Guide. Second, Q1/8 expresses their intention toapprove Recommendation T.66 at their October 1997 meeting since they wish to retain control over the issuance ofcodepoints used in their Recommendations. After discussing the liaison, the V.8bis Rapporteur group approved thefollowing changes to the V.8/V.8bis Implementer’s Guide:• Correct the wording in Table 3/V.8 associated with the facsimile codepoints, to read “Transmit facsimile from

call terminal” and “Receive facsimile at call terminal”• Add a new “reference” column to Table 3/V.8• Add a note under Table 6.2/V.8bis referencing T.66• Remove Table 6.9/V.8bis

Since Q1/8 doesn’t meet until October 1997, it was agreed to draft a reply to this liaison at the September 10, 1997V.8bis Rapporteur group meeting (Sunriver, OR).

V.8BIS REVISIONS

C. Hansen (Intel) presented V8bis 04 , a contribution from Lucent and Rockwell. It proposes a method to supportmanual mode selection in V.8bis. The approach uses a single V.8bis transaction (transaction #2) and is believed tobe compatible with existing V.8bis devices. Q4/16 agreed to include this material in the draft Appendix to V.8bis,in place of the existing material. The working text of the draft Appendix can be found in the WP1/16 report fromthe March 1997 meeting of SG 16 (TD-98(PLEN), Annex B).

V.8 REVISIONS

V8bis 02 (K. Krechmer representing VocalTec Communications Ltd.) proposes to create a new application-specificRecommendation “V.8 for Internet Access (V.8ia)” based on V.8, with the goal of reducing Internet access time(IAT). Since the ability to reduce IAT goes beyond possible changes to V.8, it was suggested that this subject



should first be raised with WP1/16 in order to determine how best to address the task. Based on existinginformation, the Rapporteur group felt that there was insufficient justification to initiate a new project at this time.

V.8/V.8BIS IMPLEMENTOR’S GUIDE

The technical content of the V.8/V.8bis Implementer’s Guide was approved by SG 16 at their March 1997 meeting.However, the guide needed editorial work after the SG 16 meeting. The editor (C. Hansen, Intel) later provided theSG 16 secretariat with an updated document, which has recently been issued as COM 21/16. The understanding isthat once this text has been reviewed by WP 1/16 at their September 1997 meeting, it will be published. Thecurrent text of the Implementer’s Guide was distributed for information to the Rapporteur group as V8bis 09 .

V8bis 07 , (C. Hansen, Editor V.8bis) presents editorial corrections to the text of the Implementer’s Guide. It wasdiscovered that the text in COM 21/16 was missing the approved PCM modem codepoints. The Rapporteur willsend this to F. Bigi, the SG 16 secretariat, to be issued as a corrigendum to COM 21/16.

Given that:• The final text of the V.8/V.8bis Implementer’s Guide needs to receive approval by WP1/16 before publication,

and• Recommendation V.8 is in need of revision since several new codepoints have been added since it was first

approved in 1994,Q4/16 agreed to the goal of consolidating the work by Determining a revision to Recommendation V.8 at theSeptember 1997 meeting of WP1/16.

V.DISPATCH

V8bis 08 (C. Hansen, Intel), notes the intention of Q11/16 to Determine H.dispatch at the September 1997WP2/16 meeting. At the last Q11/16 Rapporteur meeting (see report in this issue of CSR-T), it was decided that,without guidance from the appropriate experts concerning V.dispatch, the current text for PSTN usage will beremoved. The V.8bis Rapporteur group agreed that, since work on V.dispatch has not progressed, it would beprudent to remove the V.dispatch material from H.dispatch.

V8bis 06 (K. Chu, Rockwell) presents some proposed Terms of Reference for V.dispatch. V8bis 06 discussestechnical issues; it doesn’t address applications and/or the need for V.dispatch. K. Chu then presented V8bis 05 , aproposed session cleardown indicator and procedure for use with V.dispatch. No decisions were taken on thesecontributions.

INTELLECTUAL PROPERTY

The Rapporteur asked if anyone present was aware of intellectual property pertaining to the work on V.dispatch(statements have been made previously concerning V.8 and V.8bis). There was no response from the attendees.

Les Brown, Motorola ISG

Q7/16, DCE/DCE PROTOCOLS

V.25TER ENHANCEMENTS

F. Lucas (General DataComm, Q7/16 Rapporteur) noted that the latest V.25ter revision is made up of the previouslypublished V.25ter, COM-16-15 and TD-18(PLEN). Unfortunately, a publication date for the revised V.25ter isnot known.

At Q7/16 meetings during the March 1997 SG 16 meetings in Geneva, the issue of Asynchronous Terminal (AT)Commands in support of ISDN Terminal Adapters was considered. Q07-97-002 (J. Moughton, Hayes and Q5/16Rapporteur) discusses requirements for the control and configuration of ISDN Terminal Adapters using ATcommands. This contribution provides the first compilation of the requirements for commands for control of ISDNTerminal Adapters. R. Damm (Deutsche Telekom) indicated that he is also compiling requirements for TerminalAdapters in use in Germany which he expects to have available for consideration at the September 1997 Rapporteursmeeting. Concern was expressed by J. Moughton (Hayes) as to industry acceptance of a new Recommendation forthis new command set. The attendees expressed good support for this work; however, the Rapporteur requested thatthe attendees poll their respective country or regional standards bodies as to the use of this proposedRecommendation. It was conditionally agreed that, if work proceeds, the result would be a new Recommendation



rather than another Annex to V.25ter. J. Moughton (Hayes) indicated that he is considering the use of the ETSILayer 3 Call Control standard (a derivative of Q.931) as the basis for the command set.

Q7/16 discussed the future of V.25ter, Annex A (Procedure for DTE controlled call negotiation using V.8 or V.8bis),and Annex B (Control of V.70 and H.324 functions across an async interface). It was observed that the definition ofthe +ASTO command (store telephone number approved in March 1997) uses the dial modifier S=<location> whichis not defined. In addition, the + character was not included in the storable character listing. Q7/16 gave someconsideration of a revised V.25ter which would incorporated these corrections and incorporate the Annexes.Additional consideration will be given at the September Rapporteurs meeting.

V.25TER SUPPLEMENT

Q07-97-003 (P. Heinonen, Nokia) discusses inclusion of GSM AT commands in V.25ter Supplement. Thiscontribution is a revised copy of V.25ter Supplement with the addition of GSM commands. P. Heinonen indicatedthat there was one omission in the contribution. In the table of Section 4.9, the foloowing command should beadded between the lines for +CSCC and +CSMS:

+CMEE 9.1/GSM07.07 Report MobileEquipment Error

It was observed that GSM commands had been in an earlier draft of the supplement; however, ETSI had not yetapproved their standards at that time, which prevented their inclusion. The standards have now been approved and itis appropriate to include the commands.

It was observed that additional commands have been approved for inclusion in V.25ter which do not appear in theSupplement; a number of editorial corrections were also pointed out. It was agreed that the Supplement was in needof updating. The Rapporteur accepted the task of editor for this work, which is expected to be reviewed at theSeptember meeting.

This type of document, essentially a catalogue of AT commands, provides guidance on finding the definition andapplication of the many AT Commands that have been defined. J. Moughton (Hayes) suggested that such documentsshould be made available by the ITU-T at no charge rather than being sold, as is the present case.

ANNEX A/V.25TER

Q07-97-006 (R. Miller, Cirrus Logic/RSA) discusses command parameter extension for +A8E. It proposes theaddition of the additional value of 3 to the v8b command for Digital Cellular Equipment (DCE) controlled V.8bisnegotiation. In reviewing the contribution, B. O’Mahony (Intel) indicated that if this change were accepted,additional text would be required to describe the use of the new value. A number of questions were raised which thepresenter (R. Chen, Cirrus Logic/RSA) was not in a position to answer, and which would be referred to the author.The Rapporteur asked for the author to be present at the next meeting to resolve any open issues on this command.

V.VOICE

Q07-97-005 (C. Sneed, Rockwell, and J. Decuir, Microsoft) discusses proposed event reporting clarifications todraft Recommendation V.voice. As a result of trying to implement V.voice in equipment/software, some deficien-cies in the Recommendation were discovered. The contribution proposes the addition of complex event reporting forboth the Special Information Tone (SIT) and Calling Identity Delivery on Call Waiting (CIDCW). Q7/16 consideredthese additions and agreed with the proposal. A change to the event reporting for stuttered dial tone resulted inquestions regarding the characteristics of this event in various countries. J. Magill (Lucent UK) observed that he isaware of a system which uses frequency shift rather than an interrupted tone. In addition, it was felt that a limit on<number> for CYL (complex stutter dial tone report) needs to be included. The authors will be asked to provideanswers for the questions raised before final action on this proposed change can be taken.

Q07-97-007 (C. Sneed, Rockwell and J. Decuir, Microsoft) discusses proposed voice duplex operation to draftrecommendation V.voice. It proposes the addition of two classes of voice duplex operation (to fit in the existingmodes of non-speaker phone and speaker phone) to the V.voice Recommendation. The paper calls for the addition ofa +VTR command and extends the existing +VSP command (speakerphone). A similar proposal was brought to theTIA TR-30.2 meeting in June 1997 in the form of three contributions. At that meeting, the attendees weresomewhat confused by the proposal and its use. Considering this was the first time the Rapporteurs group had seenthis proposal, a number of questions arose and the group felt additional time was required to consider the proposalpresented. Those members of the group with questions were asked to contact the authors directly. It was also thedesire of the group that either or both authors be in attendance at the September 1997 meeting.



OUTGOING LIAISON

Q07-97-004 (B. O’Mahony, Intel) discusses proposed liaison to Q11/16, concerning H.multilink; Q07-97-004addendum contains the draft liaison. B. O’Mahony (Intel) indicated that work is being progressed in Q11/16on a mechanism known as H.multilink to support multilink (e.g., two telephone lines and four modems for oneH.324 session) operation of H.324 terminals. Currently Q11/16 is specifying the use of Transparent sub-Mode (notalways implemented in V.80 products) and requiring the DTE to perform two layers of HDLC-like bit stuffing.Q07-97-004 proposes that H.multilink use V.80 Framed sub-Mode procedures instead, which avoid theseproblems and also provides tolerance for transmitter underrun. Q7/16 agreed that a recommendation should be madeto Q11/16 that they consider Framed sub-Mode for H.multilink, which can be used with modems operating in V.80Framed sub-Mode. Since formal liaisons do not take place between Rapporteurs in the same Study Group, the textof the concerns of Q7/16 (the body of the Q07-97-004 Addendum) will be appended to the meeting report and willbe sent to the Q11/16 Rapporteur by the Q7/16 Rapporteur.

Fred Lucas, General DataComm

Q8/16, DCE/DCE PROTOCOLS

V.76

Q8-04 (L. Lucena, AT&T Labs, introduced by J. Magill, Lucent) discusses a new multiplexing technique usingtimers rather than the suspend/resume mechanism of V.76. The document had already been presented at the Q18/16meeting in Amsterdam (see report in this issue) and was passed to the Q8/16 group for information. The applicationfor the technique is on the local loop where the new technique could be part of an SVD (Simultaneous Voice Data)mechanism to permit, say, the simultaneous existence of an Internet connection and a voice connection.

During the discussion it was pointed out that xDSL or V.70 could provide the same functionality. J. Magill(WP1/16 chair) agreed to keep Q8/16 informed of any further work in the field and to make sure that the Q4/15group were also informed.

The group agreed to do nothing with the document.

TRANSPORT OF V.25TER COMMANDS

Q8-02 and Q8-03 (C. Hansen, Intel) give some reasoning for the need for transporting V.25ter commands, such astelephonic signaling, from DCE to DCE and propose a method for achieving this. Q8-03 proposes the use of newcodepoints in H.245 which would be used to carry the text of the commands between the DCEs. There was generalagreement for the H.245-based approach which may be used with any link layer which provides an error-controlledlogical link between the DCEs. The overhead is about three octets per command string, which seems a reasonableprice to pay for H.245 compatibility.

C. Hansen agreed to bring a proposal to the Sunriver meeting (Oregon, September 11, 1997) for changes to H.245,and the Rapporteur agreed to look at V.42 to see whether any changes would be needed to provide the dedicated LLC(Logical Link Control) which would be required.

There was some discussion about which V.25ter commands needed to be transmitted, whether new ones were needed,how local and remote commands could be distinguished, etc. It was agreed that these matters were more appropriatefor the Q7/16 group (DTE-DCE Protocols). A joint session in Sunriver might be a good way of proceeding.

INTELLECTUAL PROPERTY

J. Magill believes that Lucent possesses IPR in the timer scheme described in Q8-04; he will check this if thescheme is taken further.

It was felt that the concept of transporting V.25ter commands between DCEs may be covered by patents but no onewas certain of this.

Bill Pechey, Hayes UK



Q23/16, PCM MODEM

The primary goal of the Q23/16 Rapporteur meeting was to reach decisions on the data mode aspects of V.pcm -Issue 1. PCM’97-28 is the draft report of the Q23/16 rapporteur meeting May 1997. PCM’97-58 is the reportof the June TR-30.1 PCM modem ad hoc meeting.

AGREEMENTS LIST

PCM’97-59R1 (L. Brown, Chair TR-30.1) is the latest list of agreements for the V.pcm Recommendations fromthe TR-30.1 PCM modem ad hoc meeting, June 10-11, 1997. The contribution was approved. A list of openissues is attached.

DOWNSTREAM MODULATION

PCM’97-61 (presented by G. Griffith, Rockwell) is a multi-company contribution proposing the use of thefollowing in V.pcm - Issue 1: shell mapping, convolutional spectral shaping, and a closed form equation fortransmit power. It also proposes that the digital modem transmit first during startup Phase 3. The sourcecompanies for this paper are: Adtran, Ascend, Cisco, Compaq, Lucent, Matsushita, Microcom, Motorola,MultiTech, Racal-Datacom, and Rockwell.

PCM’97-76 (R. Williams, 3Com) is a multi-company contribution proposing the use of modulus conversion inV.pcm. The source companies for this paper are: 3Com, Cirrus Logic, ESS, General Datacom, LAKE Datacomms,IBM, and Texas Instruments.

SPECTRAL SHAPING

PCM’97-62 (M. Ali, Texas Instruments) presents further results on flexible trellis based spectral shaping. Itcompares the performance of 2-state and 4-state codes, suggesting that 2-3 dB more suppression is possible with a 4-state code.

PCM’97-69 (H. Yeh, PC-Tel) compares the implementation complexity of the cost functions for the variousspectral shaping techniques.

PCM’97-70 (E. Freed, V. Demjanenko, and F. Hirzel, VoCAL Technologies) contains an evaluation of severalspectral shaping methods based on a simulated receiver.

PCM’97-72 (M. McLaughlin, LAKE Datacomms) discusses the implementation complexity of the SDR(sequence determined redundancy) spectral shaping technique for the case when all of the Finite Impulse Response(FIR) filter taps are equal to one, and each of the future output energies is weighted equally. PCM’97-73 (M.McLaughlin, LAKE Datacomms) discusses reasons for employing spectral shaping, and compares some candidatetechniques based on these reasons. The paper recommends that the SDR method of spectral shaping be adopted.

PCM’97-74 (R. Nuthalapati, Analog Devices) discusses potential pitfalls in using a biquad filter for spectralshaping.

MAPPING/FRAMING

PCM’97-65 (S. Ólafsson, Rockwell) further compares the minimum distances for shell mapping and modulusconversion, based on the data signaling rates agreed to at the PCM modem ad hoc meeting in Costa Mesa, June1997. The contribution suggests that the V.34 shell mapping algorithm be used for V.pcm.

REGULATORY

PCM’97-67 (S. Ólafsson, Rockwell) addresses transmit power limitations in V.pcm. It proposes that theRecommendation specify in detail how the digital PCM modem should evaluate the transmit power of constellationssupplied by the analog PCM modem.

STARTUP PROCEDURES

PCM’97-63 (K. Krechmer, on behalf of VocalTec Communications Ltd.) discusses the temporal components ofInternet access time (IAT) and proposes ways to decrease this time in V.pcm. Specifically, for V.pcm - Issue 1, itproposes modifications to V.8 to permit user data exchange during the V.8 negotiations. This contribution is acontinuation of PCM’97-06 (K. Krechmer on behalf of VocalTec) which was presented at the last Q23/16 meeting



in La Jolla, May 1997. A companion paper was also presented at the Q4/16 V.8bis Rapporteur meeting (above),proposing explicit changes to V.8.

PCM’97-66 (S. Ólafsson, Rockwell) proposes a framework for specifying digital impairment probing sequencesthat would allow the analog PCM modem to select from a wide range of sequences specified by a set of parameters.PCM’97-71 (M. McLaughlin, LAKE Datacomms) contains a similar proposal.

PCM’97-79 (N. Dagdeviren, Lucent) proposes a means to design a code based probing sequence for Phase 2startup in V.pcm.

NETWORK CHARACTERIZATION

PCM’97-75 (V. Demjanenko, VoCAL Technologies) provides a good detailed discussion of the digitalimpairments found in the network, and the means to compensate for these impairments.

DRAFT RECOMMENDATION

PCM’97-60 (R. Williams, V.pcm Editor) is the latest draft of V.pcm - Issue 1. Q23/16 reviewed the draft. SinceV.54 test loops are currently undefined for asymmetric data rates, it was agreed to remove the reference to V.54 insection 2 and interchange circuits 140 and 141 in section 7, and to add a note in section 10 indicating that test loopsare for further study. Q23/16 then approved the revised document as baseline text.

OTHER CONTRIBUTIONS

PCM’97-68 (D. Walsh, 3Com) proposes that digital PCM modem to digital PCM modem connections beaccommodated in the Recommendation, and discusses areas of work necessary to accomplish this.

PCM’97-77 (L. Brown, Motorola) proposes modifications to V.8 (2 new bits) to accommodate both digital PCMmodem to digital PCM modem connections, and the negotiation of V.pcm - Issue 2.

DISCUSSION AND AGREEMENTS

First, the proposals for downstream data mode techniques were listed. A summary was then given by a proponent ofeach technique. This was followed by a question period. A straw poll of ITU-T members present was then con-ducted to determine the level of support for each of the following proposed mapping schemes, with the followingresults:

• Supported shell mapping (9): Lucent Technologies, Rockwell, Cisco, Matsushita, Racal Datacom, Telindus,Bay Networks, Philips, and Motorola.

• Supported modulus conversion (7): General Datacomm, 3Com, IBM, LAKE Datacomms, Texas Instruments,Cirrus Logic, and ESS.

• Abstained (7): Hayes, Siemens, Deutsche Telekom, Nokia, Helsinki Telecom, British Telecom, Analog Devices

A straw poll was conducted to determine the level of support for each of the proposed spectral shaping schemes, withthe following results:

• Supported Convolutional Spectral Shaping (7): Rockwell, Motorola, Lucent Technologies, Racal Datacom,Analog Devices, Cisco, and Matsushita

• Supported maximum symbol inversion (4): General Datacomm, 3Com, Texas Instruments, and Cirrus Logic.• Supported Sequence Dependent Redundancy (1): LAKE Datacomms.• Supported frame inversion (1): ESS.• Abstained (10): Siemens, Deutsche Telekom, Telindus, Hayes, IBM, Philips, Nokia, Helsinki Telecom, British

Telecom, and Bay Networks.

Finally, a straw poll was conducted to determine the level of support for each of the proposed spectral shaping filters,with the following results:

• Supported biquad - running filter sum (6): Rockwell, Lucent Technologies, Cisco, Matsushita, Racal Datacom,and Motorola.

• Supported one running digital sum (5): 3Com, Cirrus Logic, Texas Instruments, ESS, and Analog Devices.• Supported high order filter (1): LAKE Datacomms.• Supported two running digital sums (0): no support.• Abstained (10): General Datacomm, Hayes, Nokia, Helsinki Telecom, Telindus, Deutsche Telekom, Bay

Networks, Philips, Siemens, and IBM.



After further discussion, it became apparent that the Q23/16 was still very divided on each of these downstream datamode issues, and no compromises were offered during the meeting. As a result, the primary objective of this meet-ing was not achieved and completion of the Recommendation for Determination in September 1997 is in jeopardy.

During the discussions, the group did reach the following agreements:

• Approved PCM’97-60 (R. Williams, V.pcm Editor) as baseline text for V.pcm - Issue 1.• Agreed to remove the current text on test facilities (interchange circuits 140 and 141 in section 7, and the

reference to V.54 in section 2), and to add a note in section 10 that test loops are for further study.

• Agreed to support digital PCM modem to digital PCM modem functionality. How to accomplish this still needsto be worked out.

• Agreed to no longer consider the mapping modifier proposal in PCM’97-30 (Floreat/S3).• Agreed to a means of handling the regulatory/power issue: The digital PCM modem indicates its maximum

power constraint. Both the digital and analog PCM modems use a common method to determine an upper boundon the transmit power (the exact calculation is still to be determined). Agreed not to specify what action to takeif the modems don’t comply with the regulations.

• Agreed to no longer consider the two running digital sum spectral shaping filter function.• Agreed to use the structure of the V.34 Phase 2 startup for Phase 2 startup in both V.pcm - Issue 1 and Issue 2

(Rapporteur’s note: Since it has not been decided which modem will transmit first in Phase 3, the digital or theanalog modem, the earlier agreement on modem role needs to be amended).

• Agreed to include a bit in INFO1a to indicate how to proceed into Phase 3 startup, either with PCM or V.34modulation, those being the only two choices allowed.

OUTGOING LIAISON

PCM’97-78 (B. O’Mahony, Intel) is a proposed liaison from Q23/16 to Q4/15 concerning the potential impact ofthe deployment of Asymmetric Digital Subscriber Loop (ADSL) technology on V-Series modem performance,which may be impacted by the characteristics of “ POTS splitters (filters to separate Plain Old Telephone Systemand ADSL signals)”. This liaison was reviewed, and a revised liaison, PCM’97-80 (B. O’Mahony, Intel) wasproduced. After minor editorial changes, this liaison was approved by the Q23/16. The final text of the liaison iscontained in PCM’97-80R1 .


Q23/16 AD HOC MEETING ON V.PCM STARTUP

The goal of this meeting was to progress the work on V.pcm - Issue 1 startup.

The group focused on Phase 2 and Phase 3 structural issues. Excerpts from Recommendation V.34 and contributionPCM’97-17 (D. Walsh, U.S. Robotics) were distributed to help with the discussions.

The ad hoc committee reached the following agreements which it will propose to the Rapporteur group for approval:

1) The analog PCM modem should transmit the same sequence of signals during Phase 3 as current V.34 modems.Specifically: S, S-bar, MD, S, S-bar, PP, TRN, J. The information content of J will likely differ. Thetransmission of J should be interruptable by the digital modem by the same mechanism as in V.34 (S, S-bar).

2) Signals should be kept to a multiple of 6 symbols in length to the extent possible.3) The analog modem should specify means to terminate early the transmission by the digital modem of both the

Phase 3 equalizer training segment and the digital impairment learning segment.4) The transmission by the digital modem of the Phase 3 equalizer training segment should use only a 2-point

(single magnitude) constellation.5) The group should focus on the following two structures for Phase 3 startup (Figures 1 and 2).

The dotted lines in Figure 1 above indicate that the analog modem may or may not be transmitting during thereception of the digital probe sequence. If the analog modem is transmitting during this time, digital probing iseffectively being done during Phase 4 (full duplex startup). Signal R is a tonal signal, used to interrupt the V.34training sequence (during J).



DigitalModem

AnalogModem S S V.34 TRN

RRX TRN Digital Probe

Figure 1. Digital modem transmits first.

DigitalModem

AnalogModem S S V.34 TRN

RX TRN Digital Probe

Figure 2. Analog modem transmits first.

6) The group should focus on the followingtwo structures for the analog modem receiver training segment of Phase 3 startup:

–Signal R is tonal in nature in Figure 3. Signal R-bar is a 180 degree phase reversal of signal R. The first 2-point training sequence is short term periodic for fast equalizer training. The second 2-point training sequence isscrambled. The same signal points (transmit power) are used for both 2-point sequences. Durations of thesesequences are still to be determined.

–Signal R is short term periodic in Figure 4 for fast equalizer training. Signal R-bar is a 180 degree phasereversal of signal R. The 2-point training sequence is scrambled. Durations of these sequences are still to bedetermined.

Whether the transmit power for the 2-point training segment(s) in Figures 3 and 4 should be fixed (signal pointsspecified in the Recommendation) or variable (negotiated during startup) is still to be determined.


R R 2-point 2-point

periodictonal scrambled

Figure 3. Signal R is tonal in nature.

R R 2-point

scrambledperiodic

Figure 4. Signal R is short term periodic.



ROSTER FOR SG 16 Q4/16, Q7/16 AND Q23/16 RAPPORTEUR’S MEETINGSJULY 7 – 11, 1997, DUBLIN, IRELAND

Dick Stuart, 3Com Q4/16 RapporteurFred Lucas, General Datacomm Q7/16 RapporteurBill Pechey, Hayes UK Q8/16 RapporteurLes Brown, Motorola ISG Q23/16 Rapporteur

3Com Dale Walsh3Com Richard WilliamsACTION Consulting Ken KrechmerAlgoTron Bill HodgkissAltocom Haixiang Liang, Ph.D.Analog Devices Rao NuthalapatiBay Networks Qingli Liu, Ph.D.BT Keith HaltonCanon Masao HosakaCirrus Logic/RSA Raymond ChenCisco Kevin RileyCSR Elaine Baskin, Ph.D.Deutsche Telekom Ralf Ranier DammEquator Karl ZhaoESS Ping DongGDC Yuri GoldsteinGDC Fred LucasHayes Bruce AdamsHayes John MoughtonHayes Bill PecheyHelsinki Telephone Juha KauppiIBM Gottfried UngerboeckIntel Chris HansenIntel Barry O’MahonyLAKE Datacomms Tony Fagen

LAKE Datacomms Michael McLaughlinLAKE Datacomms Brian O’SullivanLucent Nuri DagdevirenLucent John MagillMicrosoft Lawrence SteenMotorola Les BrownMotorola Vedat EubogluNokia Petri HeinonenNokia Lippo RantanenPanasonic/MGCS Alan PughPC Tel Han YehPhilips Véronique BrunRacal Research Chris FirthRockwell Keith ChuRockwell Glen GriffithRockwell Sverrir OlafssonSGS Thomson Antonio AlvarezSiemens Thomas HenkelSiemens Neal KingTelindus Paul AertsTelindus Erik HulsmansTexas Instruments Murtaza AliTexas Instruments Jean Pierre HoudardTransend Marcus TschoepkeVoCAL Technologies Victor Demjanenko

The next issue of Communications Standards Review – Telecommunications (Vol. 8 #8) is scheduled forSeptember-October 1997.



REPORT OF IMTC AD-HOC GROUP ON HARMONIZATION OFCONFERENCING PROTOCOLS, JULY 8 – 10, 1997, ANDOVER, MA

Editor’s note: CSR normally reports only upon meetings of formal standards organizations. Since this report of anindustry group ad-hoc may affect the work in formal standards committees that CSR reports on, we feel that theconclusions of this meeting are relevant to our subscribers.

The IMTC Ad-Hoc Group on Harmonization of Conferencing Protocols met to discuss the harmonization of theITU-T H.3xx series multimedia videoconferencing standards with the ITU-T T.120/T.130 series standards forconference control and data conferencing. This harmonization is deemed to be urgently needed, especially as newmechanisms in H.323 (including H.225.0 and extension of H.245) potentially conflict with T.124 (GCC) and T.132(AVC) mechanisms.

The conclusions of this meeting were based on the following principles:

• We must harmonize H.3xx and T.1xx in all future work – we cannot continue to treat them separately. Q3/16(T.120 work) and Q14/16 (Interworking Protocols) should hold joint meetings in the future where control issuesare concerned.

• In the short term, we must fix particular protocol conflicts between Q3/16 and Q14/16 that still remain.• In the longer term, we should evolve to a single set of harmonized protocols where there is one preferred method

for any function.• Protocols that exist today, but which are not the long-term preference, must continue to be supported for

backward compatibility. Simple point-to-point terminals can use the existing standards (to H.245 rev. 3), but weshould not further extend the non-preferred modes.

• Procedures used for conference control should eventually be identical regardless of the particular combination ofmedia that will be used in the conference.

• “T.120” and “data conferencing” are not synonymous. T.120 includes an infrastructure that supports both dataconferencing applications as well as multipoint-aware control protocols. Those control protocols shouldeventually be usable regardless of whether or not data applications are in use, and should be able to apply to theconference as a whole, not just the data applications.

T.124 APPENDIX I RE-AFFIRMED ; PRINCIPLES SHOULD BE EXTENDED

The group re-affirmed that the T.120/H.3xx harmonization guidelines in T.124 Appendix I (“Relationship of T.120to H.243 in H.320 Conferences”) should be implemented, and recommends that the principles there should beextended to cover all Switched Circuit Network cases, including H.324 and H.310.

ALL DATA -ONLY T.120 CALLS SHOULD LEAD WITH H.3XX

Two problems have been observed related to T.120/H.3xx conference association and interworking:

• Confusion about linking pre-existing T.120-only data conferences with later-started H.3xx conferences (inparticular, H.323)

• Incompatibility between T.120 data conferences operating on the same network transport (POTS, ISDN, LAN,ATM…) but using different T.123 stacks (e.g., T.120-on-ISDN vs. T.120-on-MLP-on-H.320, etc.)

The group recommends that both problems be solved by requiring that all T.120 conferences, including data-onlyconferences without video or audio, be started within the context of an H.3xx call. That is, first an H.3xx callshould be set up, then T.120 should be started using H.242/H.245 mechanisms. In the future, T.120 should not beused outside an H.3xx conference, except for backward-compatibility with earlier equipment.

We note that this implies that audio should be made optional in all H.3xx conferences (H.320 and H.323 currentlyconsider audio as mandatory), to allow efficient data-only conferences (H.3xx adds negligible overhead to data-onlycalls using T.120, so this should not affect performance). A product which supports only data applications (notaudio or video) would not need to implement the audio and video related parts of H.3xx, but would need the basicinfrastructure of H.3xx.

“H.UNIFIED” PROJECT TO UNIFY H.3XX WITH T.1XX

Three attachments to the original IMTC meeting report indicate the result of much discussion of principles,requirements and alternatives:IMTC-att-1, Our 12 Guiding Principles



IMTC-att-2, Core and Extended FunctionsIMTC-att-3, Issues Identified With Harmonization

The group finally agreed on a general path to fully harmonize H.3xx and T.1xx conferencing protocols.

1. We will immediately begin a project to define the interaction of existing H.245 (H.243-derived) conferencecontrol and audio/video control functions with their equivalents in the T.120 series as well as harmonize H.225.0call/conference control with equivalents in T.120 series.

2. We agree that these H.243-derived functions may be used, but that their T.120 equivalents are the preferred modeof operation.

3. We will clearly define a subset of H.245 Version 3 functionality which belongs in H.245, and agree that all otherfunctions should be migrated to the T.120 series (if not present there already).

4. We will make an “iron rule” that we will not further extend H.245 functions outside the above agreed long-termscope of H.245; we will not further duplicate any T.120-series functions in H.245.

5. We will generate an “H.UNIFIED” architecture for a fully integrated H.3xx/T.1xx conferencing protocol andevolve the current standards toward this over time.

The “H.UNIFIED” architecture will move most existing H.245 functions into one or more T.120 applications.Only strictly point-to-point H.245 functions, such as Logical Channel control, multiplex control, and local flowcontrol, will remain in H.245.

In Figure 1, “H.UNIFIED” Block Diagram, dotted lines represent flows of control information. Changes from theexisting H.3xx/T.1xx system include:

• Move some H.245 functions (cap exchange, H.243 functions, probably others) into T.124• Define APEs for audio and video (possibly per codec; possibly per media type)• Define “Real-Time Multipoint Services” to support real-time applications such as H.26x video and G.7xx audio.• H.UNIFIED system will rely exclusively on T.120 mechanisms for conference control and audio/visual control

(except for backward-compatibility with earlier systems).

Physical Layer (LAN, POTS, ISDN, ATM )

Call Setup

----H.225.0, V.25ter Q.931

P-to-PControl

----LC, Mux, FC Part of H.245

H.22x Multiplex/Network

MCS

Node Controller

Real-Time Multipoint

Services

Conf. Control

----GCC.1

Non-RTAPEs

Mixed APEs

Real-Time APEs

Application(s)

Standardized Infrastructure

Standardized Application Protocols

H.243 Conf.

Control

T.123

A

A

Application Control Services(Roster, Caps, Registry, etc )

GCC.2

H.243 A/V Ctrl

Link-specific Point-to-PointControl (in H.245)

T.126,T.128,etc.

Audio & Video (T.132 + codecs)

Figure 1. “H.UNIFIED” Block Diagram



H.UNIFIED is intended to include a generic set of infrastructure services and distinguish these from application-specific protocol entities (APEs). This design allows future codecs and media streams to be standardized withoutrequiring revision of the infrastructure standards, such as H.245.

NEXT STEPS

The following immediate action items were agreed as next steps:

Step 1:a. Fix definition of how existing T.124 control integrates with H.323.b. Re-commit to existing defined H.320=>H.324 integration with T.120 (per T.124 App. I); enhance details if

needed.c. State intention to migrate to “H.UNIFIED”-based control for future.

Step 2:a. Architect long-term scope of H.245 vs. T.120 control.b. Commit to non-expansion of H.245 outside of scope.

Step 3: Evaluate which parts of T.130 fit with the new plan and approve them in January, 1998.

Step 4: Re-work remaining functions of T.130 in new model.

Step 5: Work toward gradual evolution toward H.UNIFIED.

WORK ITEMS

• Review H.243, H.245, T.132 for the functions we want to move into other places• Consider reworking division of functions (floor control, roles, etc.) between T.124 and T.132 where appropriate• Extend generic capability exchange mechanism in T.124 (GCC) to account for H.245 requirements

(simultaneous/alternative capabilities, preferences)• Define APEs for audio and video including actual audio/video caps (defines how legacy H.243, H.245 are used as

well as T.120 mechanisms)• Define Real-Time Multipoint Services per figure• Define mapping (proxy?) for H.243 to/from GCC

MEETING AUGUST 18 - 20

The group will meet August 18-20 in Lexington KY USA, hosted by DataBeam Corporation, who will sendinvitations on the e-mail reflectors. The meeting will work on the action items listed above, with the goal ofproducing contributions to the appropriate ITU-T SG 16 Questions.

The meeting is open to representatives of all IMTC member firms. As well, individual experts active in the ITU-Tstandardization work in SG 16 Questions 3, 11, 12, 13, and 14 on H.3xx and T.1xx are invited to attend.

Dave Lindbergh, PictureTel

MEETING ROSTER FOR IMTC AD-HOC GROUP ON HARMONIZATION OF CONFERENCINGPROTOCOLS, JULY 8 – 10, 1997, ANDOVER, MA

Dave Lindbergh, PictureTel IMTC Ad-Hoc Co-Chair

3Com USA Ming-Whei FengAccord Video Telecom Israel Roni EvenBT UK John BoucherBT UK Mike NilssonBT UK Trevor PeersDataBeam USA Bill QuinnDataBeam USA Neil StarkeyDelta Info Systems USA Gary ThomLucent USA Glen FreundlichMicrosoft USA Toby Nixon

Multilink USA Chuck GrandgentNortel Canada Nancy GreenPictureTel USA Mark ReidPictureTel USA Dave LindberghPictureTel USA Jeff BernsteinTELES AG Germany Joerg OttVideoServer USA Charles BuresVideoServer USA George KajosVideoServer USA Glenn Stewart



REPORT OF QUESTION 4/15, ACCESS NETWORK SYSTEMS (XDSL),RAPPORTEURS MEETING, JULY 14 – 15, 1997, COLUMBIA, MD

CM-032 , a liaison from the Q23/16 Rapporteur Group (L. Brown, Motorola), asks that new xDSL systemsconsider the use of modems on the same cable system. It requests that power level of potentially interfering signalsin the 0-4 kHz band be limited to –75 dBm. Also it requests that the lowpass section of POTS splitters notintroduce significant attenuation or phase distortion in this band.

STANDARDS PROGRESS

ANSI T1E1.4

T. Starr (Ameritech) gave a verbal report on the status of the Very High Speed ADSL (VDSL), High-rate DigitalSubscriber Loop (HDSL), Spectral compatibility and Issue 2 ADSL projects. He reported excellent progressdeveloping standards in all areas.

CAP/QAM RADSL Ad hoc

CM-012 (M. Humphrey, Paradyne) is a draft Outline of the Carrier-less Amplitude Modulation Phase Modulation/Quadrature Amplitude Modulation Rate Adaptive Digital Subscriber Loop (CAP/QAM RADSL) document.Agreements were reached on the modulation (dual mode transmitter), Signal Masks, Spectral Placement, and BaudRates. It was noted that there had been a recent agreement for separate specifications for CAP and QAM which willimpact on the dual mode.

CM-013 (M. Humphrey, Paradyne) is a list of preliminary discussion points on User Needs for CAP/QAM. It wasclarified that there was no agreement in the Q4/15 ad hoc group on any of these points.

ADSL Forum

T. Starr (Ameritech) gave a verbal report on the ADSL Forum. He reported that several documents were going outfor ballot, and that attendance continues to grow.

ETSI

S. Schmoll (Alcatel) reported on the ETSI work on HDSL. Among other things, he reported that they areinvestigating the simultaneous transmission of ISDN and another source (e.g., analog voice) in HDSL.

DRAFT RECOMMENDATION G.HDSL

CM-004 (S. Schmoll, Alcatel) is a one page reference to draft Recommendation G.hdsl which plans to use echocancellation methods. This is based on the ETSI ETR (ETSI technical report) 152 Edition 3. It also proposesreferencing in Annex A a two wire pair HDSL system (ref. T1E1.4/92-002R3, Technical report on HDSL).

CM-011 (S. Schmoll, Alcatel) is the list of questions and proposed answers for referenced documents as given indraft Recommendation A.xx. This is a Determined document from the TSAG, Generic procedures for includingreferences to document of other organizations in ITU Recommendations.

CM-029 (G. Sebek, France Telecom) raises the issue of the informative nature of the ETSI Technical Report(ETR) being referenced.

DRAFT RECOMMENDATION G.ADSL

CM-005 (R. Brandt, Motorola) is a one page reference Recommendation document. It references ANSI T1.413-1995 (DMT) as the underlying technical standard for G.adsl.

CM-010 (R. Brandt, Motorola) is the list of questions and proposed answers for referenced documents as given indraft Recommendation A.xx, similar to CM-011 , above.

CM-030 (G. Sebek, France Telecom) proposes that either the ANSI Standard (DMT) be made informative only orthat an Annex be added that would spell out the level of requirement of each clause of the ANSI standard.

At this point, in response to a proposal from the Rapporteur, J. Bingham (Amati) assumed the role of editor forfuture work on G.adsl (referred to as G.adsl-2).



G.ADSL-2

CM-006 (J. Bingham, Amati) proposes that a table of contents be the means of tracking and coordinating thework.

CM-026 (K. Cavanaugh, Motorola) is the latest version of T1.413 Issue 2 ADSL Standard. It was brieflyreviewed, highlighting the differences with relation to Issue 1. POTS interworking was highlighted as an issuewhich could benefit from the group’s input.

CM-024 (M. Tzannes, Aware) proposes that a modified version of T1.413 Issue 2 (removing requirements forbackward compatibility with T1.413) be used for the ITU Recommendation.

CM-023 (M. Tzannes, Aware) proposes that bit swapping be optional in the ITU Recommendation.

IPR

CM-002 (R. Stuart, 3Com) identifies Amati, Alcatel and Motorola as potential holders of Intellectual PropertyRights (IPR) on T1.413 (either issue). Amati and Alcatel confirmed that they hold IPR. Motorola indicated thatthey would report later in the meeting.

There was considerable discussion about whether Intellectual Property (IP) is a consideration when choosing aparticular technology. There were statements on both sides of this issue. ITU Policy is that, if the appropriatestatement is made, the decisions should be made purely on the technical merits. CM-027 is a copy of the ITUPatent policy.

There was some early discussion on IPR where it was clarified that at least one company (Amati) was able toimplement Discrete Multi-tone Carrier (DMT) without infringing on Telebit’s IPR. Lucent expressed reluctance todeclare any IPR statement at this time, indicating that they will wait until there is a draft Recommendation available.3Com, Alcatel, Amati, Analog Devices, Aware, Motorola, TI had indicated previously that they believe they holdIPR on T1.413. Radish was identified as a potential IPR holder on V.8. It was also decided to add Telebit to the list(in spite of the above statement).

POTS SPLITTERS

CM-021 (P. Santos, 3Com) identifies issues related to the specification of POTS splitters in an ADSLRecommendation.

TESTING

CM-007 (T. Starr, Ameritech) provides a copy of the sections of ANSI T1.413 which address testing issues. M.Tzannes (Aware) proposed that test procedures be specified for both compliance and interoperability.

CM-020 (M. Kawasaki, Nippon Telegraph and Telephone) proposes that the G.adsl testing specification shouldnot be based on the testing sections of either ANSI T1.413 Issue 1 or Issue 2 as these sections are based on theNorth American network.

DATA CORRECTION/COMPRESSION

CM-009 (M. Tzannes, Aware) proposes that only one error correction scheme be specified (for both upstream anddownstream).

MIB

CM-008 (T. Starr, Ameritech) is a copy of the ADSL Forum’s Working Text draft for an ADSL Line ManagementInformation Base (MIB).

LOGICAL INTERFACE

CM-014 (G. Whelan, Aware) proposes the use of as simple an interface as possible between the modem and thenext device, which can support a number of popular industry interfaces including USB, Firewire, Ethernet, andothers. It notes that T1.413 Issue 2 specifies numerous interfaces, some of which are quite complex.

HANDSHAKE/STARTUP SEQUENCES

CM-015 (M. Tzannes, Aware) proposes that a front-end protocol similar to V.8 or V.8bis be specified.



CM-018 (W. Chen, Texas Instruments) proposes the use of channel probing tones for a modem-like handshake todistinguish between HDSL, ADSL and ADSL Lite.

CM-025 (V. Rao, 3Com) proposes that an ADSL version of V.8 (out of the voice band) be used for the G.adslhandshake.

GENERAL

CM-022 (C. Hansen, Intel) identifies issues relating to the ITU ADSL Recommendation. Goals for work on theRecommendation include:• Use existing Recommendations as much as possible (e.g. V.8, V.8bis)• Simultaneous modem (on the voice channel) ADSL operation• Optimization of bit rates (not higher than needed)• Ease of customer installation• Break up the work into specific areas of study (versus one all-inclusive Recommendation).

CM-031 (J. Loehndorf, 3Com) proposes that a operations channel be established between the ATU-C and ATU-Rbased using I.432, I.361, and I.610 protocols when an ATM U Interface is present.

CAP/QAM

CM-033 (M. Sorbara, Globespan) proposes text for a draft Recommendation for a CAP based Rate AdaptiveADSL.

XDSLITE

CM-017 (G. Whelan, Aware) proposes the study of a 1 Mbit/s DSL, which would fit between ADSL and ISDN,referred to as MDSL (Medium speed DSL).

CM-019 (W. Chen, Texas Instruments) proposes the study of what is referred to as ADSL “Lite.” ADSL-L wouldprovide 4/2 Mbit/s (as opposed to the 10/7 Mbit/s provided by ADSL. Lower complexity and the ease ofimplementation with “off the shelf” semiconductor technologies is cited as some of the benefits.

CM-028 (R. Bell, Advanced Micro Devices) proposes the study of a “light weight” ADSL. It gives many of thesame reasons cited in the other “Lite” papers (e.g., lower complexity, lower cost, lower power requirements). Inter-net access is seen as the major application. It was noted that Advanced Micro Devices has (or is in the process of)trademarked the term “ADSL Lite”.

HANDSHAKE

The initial discussions related to using this “handshake” for mode selection, and the question of support for multiplemodes. Amati, Orckit and Motorola expressed opposition to developing a new handshake mechanism. It wasdecided to proceed with the study of a G.hs. L. Brown (Motorola) was appointed the editor for this work.

SUPPORT OF VOICE-BAND MODEMS

Ameritech agreed to the support of voice-band services, but expressed concern about the need to require support forV.pcm modems on the POTS connection associated with xDSL services. It was decided to send a liaison thatgenerally supports the use of modems on xDSL and asked for more information on the aspects of V.pcm.

G.LITE

After considerable discussion it was decided to try to develop an initial Terms of Reference (ToR) for G.lite.Motorola, NTT and NEC expressed concern over the need for this work. C. Hansen (Intel) was appointed editor forG.lite. The following points were agreed as points of consideration for this work:• Spectral compatibility with other services• Cost impact on CPE (Customer Premise Equipment) and the Central Office (CO)• Requirements on customer premises wiring, interoperability with G.xDSL.

G.TEST

It was agreed to develop a testing Recommendation drawing as much as possible on CM-007 , the test sectionsfrom T1.413-1995, (T. Starr, Ameritech). There was a suggestion to also consider the characterization work done inSG 14 during the last study period. M. Tzannes (Aware) was appointed editor for this work.



G.ADSL2 VERSUS G.DMT

After considerable discussion it was decided to adopt the following naming convention for the work of this group.

Name RepresentsG.adsl T1.413 Issue 1 based RecommendationG.dmt Issue 2 based Recommendation (formerly referred to as G.adsl2)G.lite Lower speed/ lower complexity Recommendation

CAP/QAM

After considerable discussion, and an indicative straw pole, it was decided that there was not a consensus to progressthe work on a CAP/QAM-based ADSL Recommendation.

Dick Brandt (dB Consulting)

Q4/15 MEETING ROSTER, JULY 14-15, 1997, C OLUMBIA, MD

Dick Stuart, 3Com Q4/15 Rapporteur

3Com James Joyce3Com Jim Loehndorf3Com Vish Rao3Com Paul Santos3Com Dick StuartAlcatel Ludwig EberlAlcatel Sigfried SchmollAmati John BinghamAMD Russ BellAMD Jim KubinecAmeritech Tom StarrAMP Ben BennettAnalog Devices Rupert BainesAT&T Benson WangAware Marcos TzannesAware Greg WhelanBay Networks Michael LivshitzBay Networks Aleksander PurkovicBay Networks Cuong TranBT Ian MannFrance Telecom Georges Sebek

Globespan Massimo SorbaraIntel Chris HansenLucent Subra AubtiLucent John ChenLucent Harry MildonianLucent Carl PortmanMotorola Dick BrandtMotorola Les BrownMotorola Ken CavanaughNEC Kazuuori SakaiNEC USA R. DigheNortel Syid AbbasNTT Masahisa KawasakiOrckit Jim SzeligaPacific Bell Dick Mc DonaldParadyne Marlis HumphreyParadyne Wahendra PatelParadyne Venkatraman RajagiopalanRockwell Tom GearyTI Walter Chen



REPORT OF Q3/16, DATA PROTOCOLS FOR MULTIMEDIACONFERENCING, JULY 15 – 18, 1997, REDMOND, WA

T.128 APPLICATIONS SHARING

Draft T.128 supports multipoint applications sharing by allowing a view onto a computer application executing atone site to be advertised within a session to other sites. T120C-165-e , draft T.128 (P. Romano, Polycom, Mi-crosoft, PictureTel), was reviewed and a small number of editorial corrections were noted.

T.LITE - LITE PROFILE

T120C-162-e , Lightweight Profile for the T.120 Architecture (B. Pulito, DataBeam), is draft T.Lite. The purposeof T.Lite is to provide a T.120 series profile which can be implemented in products that require minimal dataservices. Additional T.120 series functionality can be added to T.Lite as required. It was decided that T.Lite shouldbe an annex to T.120 and it should be redrafted in that form for the next meeting. No technical changes were madeto the document.

APPLICATION PROTOCOLS FOR TEXT TELEPHONY

T120C-166a-e (G. Hellström, Omnitor) is draft Recommendation T.CHAT. T.CHAT defines a protocol thatsupports multipoint text conversation. T120C-167-e (G. Hellström, Omnitor) is V.chat, a text conversationprotocol for multimedia applications. T120C-168 (G. Hellström, Omnitor), is the Q11/16 meeting report fromPortland June 24-27, 1997 on text conversion. These documents were reviewed. Since the editor, G. Hellström(Omnitor), was not present it was difficult to provide a detailed study of this work. The general consensus of Q3/16is that T.chat is currently too complex. A simplified T.chat is being proposed by an ad hoc group, which plans toschedule an audio conference with the editor to discuss the new draft. The audio conference will be announced on theT120 reflector.

MCS - T.122REV AND T.125REV

T120C-161-e (P. Murphy, Databeam), the draft of T.125 revised (MCS protocol), incorporates previously agreedchanges as well as new material into the main body of T.125rev. The Domain Reference ID was added to the ex-tended parameters. The Domain Reference ID is not a negotiated value, but will be generated by a Multi-pointControl Services (MCS) provider uniquely to identify a specific domain.

Three changes in addition to previously agreed changes to Annex A were also included in this draft. A race conditionwas removed by changing the Connection Reference ID to Domain Reference ID. A second race condition wasremoved by changing the Multicast Resynchronize Flag to Unicast Forward Flag and removing the Delayed Point-of-Entry Flag. In addition, ASN-1 was reformatted for the Data Flow Identifier for encoding efficiency.

T120C-160-e (P. Murphy, DataBeam), the draft of T.122 revised, Multipoint Communications Service forAudiographics and Audiovisual Conferencing, was presented. Segmentation will be added, requiring total lengthparameter, Begin and End flags. A decision was made to support unreliable-uniform data.

CONFERENCE RESERVATIONS

T120C-159-e (M. McEntire, MCI), draft Test for T.RES.2 reservations system to MCU system interface, isconsistent with the Edinburgh decision (May 1997) to add-in new sections which would cover the ReservationSystem to MCU protocol as they are developed. This document contains a new model section for ReservationSystem to MCU. Finalization of this work is at least a year away.

Review of T.135 (T.RES.1) relative to relevant H-series recommendations is encouraged and contributions arewelcome. T.135 User to Reservation System has been Determined and is scheduled for Decision at the January 1998Study Group 16 meeting. It has been sent to the ITU for translation.

SECURITY FOR T.120 CONFERENCES

T120C-163-e (P. Galvin, DataBeam) proposes a set of requirements for T.120 security. Requirements includesecure authentication of participants, secure transmission of application data, resource protection, scalability to largeconferences, transparency to user applications, backward compatibility and others. Security services includeauthentication, access control, confidentiality and others.



No time table has been established for this task. Q3/16 would very much like to receive assistance from Q14/16 onthis work; therefore joint meetings with Q14/16 should be held when possible.

HARMONIZATION

T120C-169-e (D. Lindbergh, PictureTel) is the meeting report of the International Multimedia TeleconferencingConsortium (IMTC) Ad-Hoc Group on Harmonization of Conferencing Protocols, July 8-10, 1997 in Andover, MA(see the report in this issue of CSR-T). After a lengthy and active discussion, Q3/16 could not reach a consensus onits results and conclusions.

Q3/16 has decided to continue to work with Q14/16 to ensure customer requirements are being met. Contributionsare welcome on this matter; this subject will be scheduled for the joint meeting of Q3/16 and Q14/16 September 8-11, 1997 in Sunriver, OR.

T120C-164-e , AVC profiles for T.132 (BT), and T120C-158-e , Proposed additions to draft RecommendationT.132 (N. Greene, Nortel), were presented, but received short discussion. T120C-158-e proposes additions toT.132 which include proposals to improve the side conferencing and audio mixing services provided to terminals.

ADMINISTRATIVE

Members are asked to distribute papers electronically for review one week in advance of a meeting to the designatedsubdirectory of ftp://ftp.imtc-files.org/imtc-site. Availability of the files should be announced by e-mail. Documentnumbers are assigned and planned dates of attendance are recorded by an automated script athttp://world.std.com/~k1om/ imtcftp.html. New drafts should have their revision date hard-coded, so that it willprint the same for all members. The t120_redmond97 subdirectory includes documents from this meeting. The nextsubdirectory will be t120_sunriver97.

The FTP site contains the latest version of all T.120 series drafts. For additional information, seehttp://www.imtc.org/imtc.

Electronic mail should be sent to members via the reflector at [email protected]. Correspondents shouldidentify themselves in the body of messages sent, since header lines showing the source do not always survive. Forinstructions to join this mailing list, send e-mail to t120-interest-request @world.std.com.

WORK PLAN

Draft Rec.SG 16March1997

WP1/16&WP2/16Sept.1997

SG 16Jan.1998

T.122 revision - d DT.124 revision d - DT.125 revision d r DT.126 revision D - -T.128 d - DT.130 r - **T.131 - - **T.132 r - **T.135 d - DT. Lite - d DT.CHAT - d DT.MCS2 - - -T120 Security - - -

d = determine, r = re-determine, D = decide

Note: ** Pending discussions during September 8-11, 1997 Sunriver, OR meeting.

Bruce DeGrasse, BJ Communications



Q3/16 MEETING ROSTER, JULY 15 – 18, 1997, REDMOND, WA

Bruce DeGrasse, BJ Communications Q3/16 Rapporteur

Accord Roni EvenBJ Communications Bruce DeGrasseBT Labs John BoucherBT Labs Trevor PeersCitrix Systems, Inc. Scott BroderDataBeam Pat GalvinDataBeam Pat MurphyDataBeam Neil StarkeyData Connection Tony DownesFrance Telecom CNET Azdine TadristIchat Marcel SamekIntel Greg KisorMCI Murry McEntireMicrosoft Steve LiffickMicrosoft Max MorrisMicrosoft Toby NixonNortel Nancy GreenePictureTel Mark DuckworthPolycom Pat RomanoStarvinson Multimedia Don PiercyTELES Jörg Ott

1998 STANDARDS COMMITTEE MEETING SCHEDULESAS OF AUGUST 4, 1997

Subject to change without notice

Committee Date(s) LocationSG 16 Jan 26 - Feb 6 Geneva, SwitzerlandETSI STQ Jan 28 - 30 ---TR-29 Feb 9 - 12 Newport Beach, CASG 15 Feb 9 - 20 Geneva, SwitzerlandTR-41 Feb 22 - 26 Scottsdale, AZETSI MTA Mar 2 - 6 Berlin or Sophia AntipolisTR-30 Mar 9 - 13 Ft. Lauderdale, FLTR-30 Apr 27 - May 1 ---TR-41 May 10 - 14

or 17-21Baltimore/ Washington Area

SG 8 Jun 9 - 18 Geneva, SwitzerlandTR-30 Jun 15 - 19 ---ETSI MTA Jun 29 - Jul 3 Munich, GermanyTR-30 Aug 10 - 14 ---TR-41 Aug 24 - 28 CalgarySG 16 Sep 14 - 25 Geneva, SwitzerlandSG 15 Oct 12 - 23 Geneva, SwitzerlandTR-30 Nov 9 - 13 San Antonio, TXTR-41 Nov 15 - 20 New Orleans or Sarasota



ACRONYM GLOSSARY

AAL ATM Adaptive LayerADSL Asymmetric Digital Subscriber Loop (Line)ANSI American National Standards InstituteAPE Application Protocols EntitiesAPI Application Programming InterfaceASN Abstract Symbol NotationATM Asynchronous Transfer ModeATMF ATM ForumATU-C ADSL Transceiver Unit - Central Office EndATU-R ADSL Transceiver Unit - Remote Terminal EndAV AudioVisualAVC Audio Visual CodingAVC Audiovisual ConferencingB-ISDN Broadband ISDNBCH Bose, Chaudhuri, and HocquenghamBFT Binary File TransferCAP Carrier-less Amplitude Modulation Phase ModulationCFR Confirmation to ReceiveCID Caller IdentificationCME Circuit Multiplication EquipmentCNG Calling Tone (T.30)DCE Data Circuit Terminating EquipmentDCME Digital Circuit Multiplication EquipmentDCS Digital Command Signal (T.30)DECT Digital European Cordless TelephoneDIS Draft International StandardDMT Discrete Multi-tone CarrierDNS Domain Name ServerDTC Digital Transmit CommandDTE Data Terminal EquipmentDTMF Dual Tone Multi FrequencyECM Error Correction ModeENP Extended Negotiaion ProcedureEP ETSI ProjectETR ETSI Technical ReportsETS European Telecommunications Standard (ETSI)ETSI European Telecommunications Standards InstituteFSK Frequency Shift KeyingGCC Generic Conference ControlGII Global Information InfrastructureGK GateKeeperGSM Global System for Mobile Communications (formerly Groupe Speciale Mobile)GSTN General Switched Telephone Network (e.g., PSTN)HDLC High Level Data Link ControlHLC Higher Layer CompatibilityIETF Internet Engineering Task ForceIMTC International Multimedia Teleconferencing ConsortiumIP Intellectual PropertyIP Internet ProtocolIPR Intellectual Property RightsISDN Integrated Services Digital Network



ISO International Organization for StandardizationITU International Telecommunication UnionJRG Joint Rapporteurs GroupLAN Local Area NetworkLLC Logical Link ControlMC Message CenterMCS Multi-point Control Services (T.122)MCU Multi-point Control UnitMIB Management Information BaseMLP Multi-Layer ProtocolMM MultiMediaMPEG Motion Picture Experts GroupMPL Multiplex Payload Length fieldMRC Mixed Raster ContentMTA Multimedia Terminal and ApplicationsMUX MultiplexerN-ISDN Narrowband ISDNNA Network Aspects (ETSI TC)ODA Open Document ArchitecturePB Personal BasePCI Programmable Communications InterfacePCM Pulse Code ModulationPDU Protocol Data UnitPE Public Inquiry (ETSI)PER Packed Encoding RulesPOTS Plain Old Telephone ServicePSTN Public Switched Telephone NetworkQAM Quadrature Amplitude ModulationQOS Quality of ServiceQSIG Requirements specified by the ITU Q series RecommendationsRAS Registration, Admission, and StatusRAST Receive And Send TerminalRFC Designation for an Internet StandardRSVP Resource Reservation Setup ProtocolRTCP Real-time Transport Control ProtocolRTP Real Time Transport ProtocolSRP Server Requester ProtocolSS5 Signaling System 5STQ Speech Transmission QualityTC Technical CommitteeTCP Transmission Control ProtocolTIFF-FX Tagged Image File Format-FaxTIPHON Telecommunications and Internet Protocol Harmonization Over Networks (ETSI

Project)TML Test ModelTSB Telecommunications Standardization Board (ITU)UDP User Datagram Protocol



1997 STANDARDS COMMITTEE MEETING SCHEDULESAS OF AUGUST 4, 1997

Subject to Change without Notice

Committee Date(s) Locat ion

TR-29 Aug 4 - 7 Santa Rosa, CA

T1A1 Aug 4 - 8 Kansas City, MO

TR-30 Aug 11 - 15 Quebec City, Canada

T1E1 CAP/QAMRADSL ad hoc

Aug 13 - 14 ---

TR-41 Aug 18 - 22 Quebec City, Canada

Q1/15 Rapp Aug 26 - 29 London

Q2/15 Rapp Aug 27 - 28 London

Q19/16, Q20/16,Q21/16 Rapp

Sep 2 - 5 Bethesda, MD

Q23/16 Rapp Sep 4 - 5 Sunriver, OR

Q4/16, Q7/16,Q23/16 Rapp

Sep 8 - 11 Sunriver, OR

Q11/16, Q12/16,Q13/16, Q14/16,Q15/16, Q18/16Rapp

Sep 8 - 11 Sunriver, OR

Q3/16 Sep 8 - 11 Sunriver, OR

WP 1/16, WP 2/16 Sep 12 Sunriver, OR

ETSI DTA Sep 15 - 17 Sophia Antipolis,France

T1E1 Sep 22 - 26 Minneapolix, MN

ETSI ATA Sep 22 - 26 Kilkenny, Ireland

US SG D Sep 23 Washington, DC


Sep 25 ---

Committee Date(s) Locat ion

ETSI TIPHON Sep 26 - 30 Boston, MA

Q4/15 Rapp Oct - Nov ---

ITU-T SG 8 Oct 7 - 16 Geneva

TR-30 Oct 13 - 17 Galveston, TX


Oct 15 - 16 ---

TR-41.5 Int. withVESA

Oct 20 - 21 ---

SG 16 LBC Oct 20 - 24 ---

ETSI MTA Oct 20 - 24 Vienna, Austria

ETSI STQ Oct 22 - 24 Sophia Antipolis,France

TR-29 Oct 27 - 30 Toronto, Canada

Q3/16 Rapp Oct 27 - 31 Toronto, Canada

Q1/16 Rapp Nov ---

Q23/16 Rapp Nov ---

T1A1 Nov 10 - 14 ---

ETSI TIPHON Nov 12 - 14 Munich, Germany

TR-41 Nov 17 - 21 San Antonio, TX

TR-30 Dec 1 - 5 Orlando, FL

Q11/16, Q15/16Rapp

Dec 2 - 5 Europe

Q1/15 Rapp Dec 2 - 5 Geneva, Switzerland

T1E1 Dec 8 - 12 Sacramento, CA

ETSI TIPHON Dec 9 - 11 ---

NOTICE: THE CSR AREA CODE HAS CHANGED TO 650.All phone numbers in the 415 area code south of San Francisco changed toarea code 650 on August 1, 1997. Please change your records accordingly.

Visit the CSR Web Pages:http://www.csrstds.com

The Web Pages include an updated Telecom Acronym Definitions list, updated meeting schedules, a list of web sitesand ftp sites as listed in all issues of CSR journals, background material on telecom standards and CSR (thecompany), sample reports from CSR-T and CSS, data sheets on both CSR technical journals, and more.

Communications Standards Review –Telecommunications (ISSN 1081-4655) is published8 - 9 times per year, within days after the latest, related standards meetings. Editor: Elaine J. Baskin, Ph.D.Technical Editor: Ken Krechmer. Copyright © 1997, Communications Standards Review. All rights reserved.Copying of individual articles for distribution within a subscriber organization is permitted. Subscriptions: $595.00per year worldwide, $695.00 in electronic format. Corporate Intranet subscriptions and other discounts for additionalsubscriptions are available. Submit articles for consideration to: Communications Standards Review, 757 GreerRoad, Palo Alto, CA 94303-3024 U.S.A. Tel: +1-650-856-9018. Fax: +1-650-856-6591.e-mail: [email protected]. WWW: http://www.csrstds.com. 18907

COMMUNICATIONS STANDARDS REVIEW … And Q15/16 June 24 – 27, 1997, Portland, Or ... Texas...

Documents

Transcript of COMMUNICATIONS STANDARDS REVIEW … And Q15/16 June 24 – 27, 1997, Portland, Or ... Texas...